Spec clarification (minor): handling of version strings with leading zeros in browser UI and stores

[bershanskiy]

Extension manifest.json has to specify version and can optionally specify version_name. version_name is an arbitrary string while version has some rules applied to it. However, these rules are not very consistent across browsers, documentation, and even browser and these browser's own stores:

• Chrome Web Store displays versions with leading zeroes in parts of string, e.g., 1.01.01, would be a displayed verbatim
• Chrome UI at chrome://extensions/?id=* removes these zeroes, e.g., 1.01.01 would become 1.1.1 since 01 is essentially the same as 1.
• Chrome Developers documentation does not allow leading zeroes: "Non-zero integers can't start with 0. For example, 032 is invalid because it starts with a zero."
• Firefox is much more permissive but has a different syntax which

Of course, this is a minor difference but it could cause confusion for the user. Should specification restrict leading zeroes (or anything else) or allow them?

For reference, Semantic Versioning Specification 2 section 2 disallows leading zeroes as well:

A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

[carlosjeurissen]

Firefox is much more permissive but has a different syntax which
Seems something is missing here.

Some additional notes, version_name is unsupported by Firefox.

As for Safari, extensions are bundled with either a mac os or iOS app. The app extension, and the mac / iOS apps both have a build number and version number in addition to the versions specified by the browser extension.

Under semVer, 0.y.z is valid. So you can have a version like 0.1.0.

Another aspect which might be out of sync (did not do any tests yet) is handling of introductions / removals of version parts. Google right now sees 1.1.99.0 as newer than 1.1 yet older than 1.2.

If we happen to disallow leading zeroes (which would make a lot of sense) or make other changes, we should consider backwards compatibility. In addition to stop supporting them in manifest v4, we can start dropping support in the web stores. Yes, web store discussions are out of scope. Yet in this case it seems to make a lot of sense to bring up.

[Rob--W]

Firefox's version format has historically been quite permissive, but the format will become stricter. For details see https://bugzilla.mozilla.org/show_bug.cgi?id=1793925 and the documentation update in mdn/content#21699. The format is: up to 4 integers separated by a dot, and each integer must be at most 9 digits each, and must not start with leading zeroes before a non-zero digit.

As part of that bug, I also checked the expectations of Chrome, the Chrome Web Store, Firefox and AMO (https://bugzilla.mozilla.org/show_bug.cgi?id=1793925#c3). There were some observed differences between Chrome's documentation and the actual formats expected by the Chrome Web Store and Chrome. Despite the implementation differences, I recommend to stick with the documented format, which clearly rules out leading zeroes before non-zero digits.

P.S. version_name is not yet supported in Firefox - https://bugzilla.mozilla.org/show_bug.cgi?id=1380219