Validation error "/version" should match format "versionString" should say what the versionString format is

[diox]

Initially filed as https://github.com/mozilla/addons-server/issues/7778

Original description of the issue written by @arantius:

I tried to automatically submit a nightly build for signing and self-serving. The (partial) result was:

{
  "guid": "{e4a8a97b-f2ed-450b-b12d-ee082ba24781}",
...
  "validation_results": {
    "errors": 1,
    "success": false,
...
    "messages": [
      {
        "uid": "ba64e9016ce74252b49bc45f074ef667",
        "dataPath": "/version",
        "tier": 1,
        "message": "\"/version\" should match format \"versionString\"",
        "type": "error",
        "id": [
          "JSON_INVALID"
        ],
        "description": "Your JSON file could not be parsed."
      },
...
  "version": "2018.03.09.nightly.e7c1c74"
}

The webext docs say "see the Version format page." The version format page says "A version string consists of one or more version parts, separated with dots. Each version part is itself parsed as a sequence of four parts: <number-a><string-b><number-c><string-d>. Each of the parts is optional."

Okay, I've got five parts.

1. number a (rest, optional, omitted)
2. number a (rest, optional, omitted)
3. number a (rest, optional, omitted)
4. number a (optional, omitted), string b, (rest, optional, omitted)
5. number a (optional, omitted), string b, (rest, optional, omitted)

But, rejected. And I don't know what to fix, because I'm already compliant with the docs.

(I can make an educated guess that you actually want me to follow chrome's rules, "One to four dot-separated integers identifying the version of this extension." -- except I've had non-numeric characters work in the past so I think that's not quite it.)

[arantius]

Interesting, moving the issue here has helped me find:

https://github.com/mozilla/addons-linter/blob/053bb7a515d3c1d6fd8832da21ff3c5fa77bee34/src/schema/formats.js#L12

The actual code (I think) which does this validation. Which seems oddly restrictive, but I can reverse engineer into something that I can generate.

Out of curiosity:

• Why a max of 4 parts?
• Why no leading zeros?

I can only see two branches, either TOOLKIT_VERSION_REGEX, or every part matches VALIDNUMRX (1-5 digits exactly, no leading zeros unless the whole thing is "0"). And the toolkit regex actually only allows one to three digit-only parts, then one must-have-digits part followed by a single must-have digits then must-be-alpha string part (with optionally a dash and some more digits). So it's really hard to include non-numeric values, despite the documentation implying that it's easy.

[asamuzaK]

Out of curiosity:

• Why a max of 4 parts?
• Why no leading zeros?

See:

• Manifest - Version - Google Chrome
• Error message for versions like 1.4.0-pre.0 · Issue mozilla/addons-server#1439 · mozilla/addons-linter

The definition of the version format on version - Mozilla | MDN is unclear, and I think that error message should be made more understandable.

[moribellamy]

message should definitely be made more understandable. I got blocked submitting version 19.12.02.

side note: this restriction is pretty unfortunate. https://github.com/mahmoud/calver is a great versioning scheme for applications.

also, that chrome documentation page is a lie. i just submitted said version to chrome web store

[moribellamy]

I forgot about this, went to update my extension, and ran in to this again. any updates here?

at least a better error message is called for. i'd also like to know why no leading 0s are allowed. neither calver nor semver are supported because of this restriction.

[Dathix]

We tend to use npm version to increase the version of our extensions from our pipelines. NPM use the SemVer format which should be seen as the industry-standard in my opinion.

For the same reasons that NPM uses the SemVer format, it should be valid as a version string for extensions.

Or adapt the concept of Google that allows defining a separate version_name to contain SemVer format.

[ZachSaucier]

I also received this error when doing version 5.1.01. Changing it to 5.1.1 fixed the issue.

[arye321]

changing version 0.02 to 0.2 fixed this for me

[willdurand]

That has actually been fixed, see https://github.com/mozilla/addons-linter/releases/tag/5.20.0