Adding support of "4-digits semver" aka Explicit Versioning

[flashist]

I was wondering if anybody ever discussed a chance to add 4-digits semver approach for versioning modules described here: https://github.com/exadra37-versioning/explicit-versioning/blob/master/README.md

The reason why I think it might be useful is: there are libs/engines/frameworks, which may have breaking changes in 1 MINOR release, but as semver doesn't allow using additional numbers for differing releases, they have to either increase MAJOR versions too fast or forget about using true SEMVER approach, which causes problems for other modules / apps, which are using such modules.

As an example the pixi.js lib might be taken. https://github.com/pixijs/pixi.js

If we compare 2 releases from the 4.8.x range, we can see that they have breaking changes between them: pixijs/pixijs@v4.8.0...v4.8.8

As pixi.js developers try to keep the first number of the version to important RELEASES, they can't use it as an indicator of breaking changes, so they just don't follow SEMVER.

From the marketing point of view keeping the 1st number for very important releases is a very good idea. All people who would migrate from 4.x to 5.x versions would understand that it's a completely new RELEASE, which has nothing to do with the previous 4.x.

So, my question is: would it be able to introduce the 4th number for semver-ish versioning approach?

It doesn't actually have to be x.x.x.x format, we may find another back-compatible approaches for indicating important releases, idk, smth like r1_v2.3.4 or [email protected] (which, to my taste, looks lamer than x.x.x.x, but would be fully back-compatible with the previous approach).

It would be great to receive some feedback from you folks, thanks.

[ljharb]

Why would there be any “too fast” for increasing majors? I can see too many breaking changes as an issue, but artificially keeping the major version low doesn’t solve that.

Semver isn’t about marketing, it’s about communicating breakage.

[flashist]

For me it's obvious, why pixi.js devs use the first number as an indication of the framework major release.

But as an example, take a look into MacOs: they have 10.0 version released since March 2001, and 11.x version has been introduced only recently (June 21, 2020).

As far as I understand, they introduced 11.x versions, because they transition to the new chipset (ARM).

So for end users it's a clear message that it would be a completely new version of OS.

Imagine, if instead of 10.x - 11.x, there was a situation smth like 10.1, 10.2, 11.0, 12.0,..., 51.45, ..., 95.0, 96.0, 96.1, 97.0 (ARM chipset)

In this case the message would be lost in too big amount of different versions.

[ljharb]

I don’t see why it would be lost - for each major version, users have to read the change log, which would clearly indicate the chipset requirements.

If changing chipset is that large a change, perhaps it’s time to change the name of the project and start over at v1.0.0?

[flashist]

One of the reasons is that pixi.js and MacOs are brands. If you think about it from this perspective, it would become easier to understand, that except "based on changes" versioning, there are another approaches to give version numbers (e.g. Windows 95, 98, 2000, XP, 7, 8,9,10).

Do you really think that Apple should've used semver approach each time their API is changed, but the OS itself stays more or less the same?

In case of pixi.js all projects which uses pixi.js import it as "pixi js" not "pixi.js.v4" or smth like that, so it's easier to keep imports as they are and only fix those which stop working.

[ljharb]

I think that it's fine for projects to choose not to use semver if it doesn't make sense for them - but I equally think that semver shouldn't need to change its purpose to fit projects that shouldn't be using it.

[flashist]

The thing is that some projects, as pixi.js, exist inside of the npm-environment, and npm uses semver.

It looks like there is a way to create versioning approach which would keep semver Major.Minor.Patch paradigm, but also add a way to separate important releases.

[flashist]

An idea just came to my mind that we can support fully back-compatible versions with the next syntax:

Current versions in the package.json file can be only strings.

What if npm supported them to be either strings or object with the next syntax?

{
    release: string
    version: x.x.x
}

Where:

• release is an optional param, with default value "0" (if other is not specified).
• version is a required param, which is semver version.

I would love to receive any feedback about this idea.
Thanks.

[ljharb]

That would make things highly unegonomic. One of the major features of semver is that it's simply a version string that requires no alternate encodings to type or display.

[flashist]

Ok, got it, then we have few options to choose from:

1. Adding support of the 4th number to the semver approach: x.x.x.x (looks like the most minimalistic approach and the next step to the semver ideology).

2. The "release" param might be stricted only to numbers. So it would be able to use ranges with it the same way the ranges are used in the regular semver.

3. The "release" param might be stricted to the pre-release format of the semver, which is:

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes

4. A bit weird to my taste, but completely workable and back-compatible solution might be to enhance the semver to add a support of the optional "rXvX.X.X" approach, where X is a number. If the rX part is absent, then the parser would treat it as the "release 0". So "r0v1.1.1" and "1.1.1" would be the same version of the same release.

To be honest it looks like we went to small details too much too fast, while the main holy-warish question is still unquestioned:

Would the NPM-community accept the idea of adding the 4th number or another way for identifying releases of modules?

If yes, then we can try to find the most optimal solution for it.

[ljharb]

It seems like something that should be decided by the semver specification first, before npm even considers adopting it. See semver/semver#391, semver/semver#213, etc.

[flashist]

Thanks for the links. The semver/semver#213 discussion looks like a very same idea, that I had.

[mk-pmb]

IMO the problem is that npm should support a wide variety of projects, even apps or widgets or frameworks. SemVer's scope is for libraries that haven't (yet) grown into a framework. Thus npm should find a way to allow non-library projects to use a versioning scheme more fitting than SemVer.

[jimhigson]

Typescript is extremely popular, delivered via npm, and also does not follow semver. Some pretty interesting comments in that issue's discussion on this topic.