[QUESTION] Major version 0 and the spec

[gempain]

What / Why

The official semver spec mentions that major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. (source).

In semver's README, I read Many authors treat a 0.x version as if the x were the major "breaking-change" indicator. (source).

Do you agree that this assumption - which I fully agree with - is not valid per-spec ? In that case, I think it would be worth mentioning it in the README to avoid confusion.

In any case, I think https://semver.npmjs.com should mention this, because their (your ?) website explains what the ^ is but the exception could get people confused. If you are not maintainers of that website, do you have an idea of who I should ping ?

Where

A good place to try this out is the Npm semver calculator. Search for axios and type version ^0.19.0. Versions 0.20.x are not highlighted.

Who

• n/a

References

• n/a

Keep up the great work !

[starsparrow]

I'm in support of a change to the behavior, or additional clarification in the readme/npm semver docs.

To reiterate what @gempain said, the statement in the current documentation, "allows changes that do not modify the left-most non-zero", is not always true. It's accurate under the assumption that people only use single-digit numbers in the minor/patch version elements, but it breaks down as soon as you hit 0.10.x.

Under the "left-most non-zero" rule, a dependency with version ^0.19.0 should allow npm update to take a package from 0.19.2 to 0.22.1, but it doesn't (because the actual implementation doesn't want to upgrade the minor version at all if the major version is 0, which the author justified by talking about the 0.x version being treated as if x were the major "breaking-change" indicator).

FWIW, like @gempain I also discovered this issue when trying to figure out why axios wasn't updating after npm audit complained about a recent security issue. I wonder now if the maintainers of the parent package, @azure/ms-rest-js, didn't/don't know about the confusing semver behavior with prerelease versions. Perhaps they did, because more recent versions of ms-rest-js use node-fetch instead of axios!

[privatenumber]

I asked in semver/semver#752 and @ljharb confirmed this behavior is not apart of the semver spec.

I agree with the request that this npm-specific behavior should be explicitly documented.

(Guessing this is the right repo to make this request as npm docs: semver simply shows the readme for the semver package.)