The version field for the addon on the release-hotfix branch is not compatible with the MV3 pipeline

[gabrielBusta]

In the pull request xpi-manifest #215, we updated the add-on pipeline to generate versions compatible with MV3. Add-ons can now specify either a two-part version or a three-part version ending in 0. This update is necessary because MV3 allows a four-part version, and we need to use the last two parts as a unique build ID/timestamp. Allowing the third part to be 0 allows extensions to specify a version that conforms to the semantic versioning specification in package.json.

I see the release-hotfix branch hasn't seen any changes in a couple of years. What should we do? Push main to release-hotfix? Retire the branch? The 100.2.1 version string is causing errors upstream in xpi-manifest.

cc @mozilla-extensions/webcompat

[denschub]

I updated the branch to unblock you quickly, but I'm somewhat surprised by this.

Our current versioning scheme follows semver, and explicitly uses the last digit to indicate a hotfix release. Our version number usually follows the Firefox version it rides in, and if we, for example, wanted to ship a specific intervention for Firefox release, we'd build a 127.0.1 version, because that would be newer than the 127.0.0 shipping in-tree, but older than the 128.0.0 in beta, for example.

We have this split because we might not necessarily ship all new interventions out-of-band, because that makes QA more complicated, which is the exact opposite of what we want to happen in an emergency situation.

If I understand the change correctly, it means that we could no longer build a 127.0.1, right? What solutions do we have here? Using four digits and building 127.0.1.0 in that case?

[gabrielBusta]

Ah, interesting.

With the current implementation both 127.0.1 and 127.0.1.0 will throw a error during the pipeline build.

What the pipeline does is use the last two parts of the manifest version to store the build ID.

So 127.0.0 turns into 127.0.20240613.203322 and over-rides the 3rd part.

Before the change the 127.0.1 in package.json would have turned into something like 127.0.1buildid20240613.204008 in the manifest generated by the pipeline. Which is not compatible with the V3 guidelines.

Would a version like 127.0.20240613.203322 work?

We can revisit if it doesn't.

Off the top of my head, we could generate versions with the previous format for "manifest_version": 2 extensions or special case webcompat somehow.

[denschub]

Would a version like 127.0.20240613.203322 work?

This works. We'll never ship a .1 or something in-tree, so the timestmap-based version number would always be larger. That's all that we need.

I updated our versioning scheme docs, and we can close this. Thanks for the help! :)