4 digit versioning in npm

Question

I'm surprised that 4 digit versioning is not allowed in npm ecosystem:

https://docs.npmjs.com/about-semantic-versioning

However, I have to merge my end product from npm to other systems where 4 digits are allowed. So, my question is:

(how) can we somehow make an exception for our own projects to use 4 digits?

Answer 1

You can kind of do it but you need to substitute the last . with a -. However this is NON-standard and you should probably make sure to comply with npm's versioning in case you want to upload your project there (I don't think it can brake anything but it's still a good to keep the versioning consistent on the plattform.)

Eg. your version would look like 1.1.1-1.

I have seen in it other projects for alpha versions etcs and it allows for non standard version numbers too. Some examples from npm:

• [email protected]
• [email protected]

However be aware that when you use any of the npm version major / minor / patch commands it will not increase that number at first but simply truncate everything starting from the first - character. Example:

1.0.6-1

npm version patch

1.0.6

npm version patch

1.0.7

I think this is due to the fact that normally people use it to mark a version to be in alpha / beta / rc in that order and when the version is final you keep the version number but remove the suffix.

To automate this you would need to make your own versioning cli that knows how to handle your specific versioning scheme.

Answer 2

The direct answer to your question is a qualified yes. Some semver supporting package/versioning tools allow quad numeric version strings, but they can't parse them into fields and must use string comparisons or issue an error on comparison, which is usually what you don't want to happen when comparing version strings. In other words, you lose whatever semantics are supposed to be encoded in the four version fields. (See the Coercion topic for a description of NPM's behavior in this case)

Conversions may be possible, but are usually difficult to get right:

The semantics of various 1, 2, 3, 4,...n field version schemes varies, even when the number of fields match up. Where there is a version string such as "1.1.1" that correctly translates to another scheme as "1.1.1", the semantics of the two schemes are the same, or "1.1.1" is a special case. Where the number of fields varies, it's possible that the smaller scheme's field set can be positioned at a fixed offset within the larger schemes fields (with constant values for the remaining fields). It may also be possible to extract a subset of the larger schemes fields, to transfer into the smaller schemes fields. In any case, it is not possible to have a single version string that works in both the larger and smaller scheme without violating the semantics of one or both schemes.

Translating from one scheme to the other, requires a deep understanding of the semantics of both schemes. Many of the four digit schemes are essentially semver with an additional build counter:

X.Y.Z.B
X is major or breaking changes.
Y is minor or non-breaking feature changes.
Z is patch or non-breaking changes that do not add features.
B counts from zero after the last X/Y/Z change.

Translating from such a scheme to semver is not possible, without the entire release history from X'.Y'.Z'.0 - X'.Y'.Z'.n and some means of detecting new features and build breaks between any n and n+1. In cases such as Nuget/.NET, you can lock the B field to zero and apply semver to the remaining fields, then translation from Neget/.Net involves dropping the extra field and from semver implies appending a .0 to the version.

Either adopt semver or don't. If not, you'll just have to put up with various tools squawking about your non-compliant version strings.