Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

addon+version uniqueness won't be compatible with MV3 (new version format) #185

Closed
willdurand opened this issue Oct 20, 2022 · 13 comments · Fixed by #215
Closed

addon+version uniqueness won't be compatible with MV3 (new version format) #185

willdurand opened this issue Oct 20, 2022 · 13 comments · Fixed by #215
Assignees
Labels
enhancement New feature or request

Comments

@willdurand
Copy link
Member

The addon+version uniqueness implemented in #135 will not be compatible with MV3 because we encourage a new simpler version string format in the manifest. In practice, it means:

  • letters are no longer allowed
  • the string should have between 1 and 4 numbers separated with dots
  • each number should have up to 9 digits
  • for non-zero numbers, leading zeros are not allowed

We'll need to update the build step to account for that when MV3 extensions will start to be signed. At the moment, MV3 extensions won't be accepted by the linter, though (the linter task is blocking for privileged add-ons since #169).

@willdurand
Copy link
Member Author

This bug is semi-related to this issue, although the XPI is an MV2 extension: https://bugzilla.mozilla.org/show_bug.cgi?id=1795750

@escapewindow
Copy link
Contributor

We'll need to update this code when we decide what the version should look like.

@escapewindow
Copy link
Contributor

We could do major.minor.dot.YYmmddHHM, which would allow a unique build every 10 minutes. Or specify that addons pipeline web extensions can only specify major.minor, and do major.minor.YYmmdd.HHMMSS to keep the current unique-to-the-second versioning.

@gabrielBusta
Copy link
Member

It seems there's a warning about this in Firefox now mozilla-extensions/aboutsync#110

@gabrielBusta
Copy link
Member

I'm thinking of going with major.minor.YYmmdd.HHMMSS

@willdurand
Copy link
Member Author

I'm thinking of going with major.minor.YYmmdd.HHMMSS

We probably need to document the fact that extensions will only be able to use major.minor in their manifest. Ideally this limitation would be enforced in CI (in the https://github.com/mozilla-extensions/xpi-template repo?) so that everyone knows about the limitation.

@willdurand
Copy link
Member Author

One more thing: HH might produce leading zeros, which are not accepted by the new version format.

@jcristau
Copy link
Contributor

Can you please reconsider this new format?

@willdurand
Copy link
Member Author

Sorry, I don't think that's an option.

@willdurand
Copy link
Member Author

FYI, I landed a patch to update the version string in langpacks: https://bugzilla.mozilla.org/show_bug.cgi?id=1796531

@willdurand
Copy link
Member Author

@gabrielBusta hey, any progress on this? (I am just curious, this is the last identified bug I have for the rollout of this new version format) Thanks!

@gabrielBusta
Copy link
Member

@willdurand
Copy link
Member Author

Yay, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
4 participants