[QUESTION] contradiction of minor version increasing process in 0.x.y case

[kokushkin]

What / Why

Suppose I'm going to make a minor incrementation of the 0.x.y version of my package.
How should I do it?

According to https://github.com/npm/node-semver#versions

A "version" is described by the v2.0.0 specification found at https://semver.org/.

and https://semver.org/

Given a version number MAJOR.MINOR.PATCH, increment the:

MINOR version when you add functionality in a backwards compatible manner, and

I should do it like this 0.x+1.y

According to https://github.com/npm/node-semver#caret-ranges-123-025-004

Many authors treat a 0.x version as if the x were the major "breaking-change" indicator.

I should do it like this 0.x.y+1

What should I choose?

I've found a lot of confusion around ^, minor and breaking-change terms.
Would it be better to choose one of the sides unambiguously?

References

Related to #411

[alasdairhurst]

For 0.x.y i'd treat it as 0.MAJOR.MINOR where PATCH falls under minor.

[kokushkin]

Ok, then if you do so, how long are you going to be on 0.x.y version. Does "0." mean something for you? And if yes then what?

[ljharb]

In the npm ecosystem, version numbers only convey relative breakage - they do not convey stability, or support, or time period until a new release, or any other special meaning. If you infer some special meaning from "0.", that's on you.

[kokushkin]

So, you're saying 0.x are production ready? Then it should be explicitly stated in the docs I think (specifications of npm). Now it seems kinda opposite.

[ljharb]

Yes, everything published is production ready.

[kokushkin]

and if I want to publish something not production ready, but for people to try, how should I describe it in versions then (if not 0)?

[ljharb]

Use a prerelease.

[kokushkin]

And when I'm done I just drop "beta" and stay with 0.x.y. Ok, fine..but what's the point for me to start from 0.x.y ? I'd not be able to convey my patches versions.

[ljharb]

y would contain both minors and patches, yes. All of this is why it's a great idea to start a package at v1.0.0, but none of it changes the npm ecosystem's meaning of semver.

[kokushkin]

Ok, let's say I use pre-release (aka alfa, beta) to mark my versions as not production ready, as we agreed.
1.0.0-alfa< 1.1.0-alfa <, then if I make a breaking change should I increase my major version, so the next would be 2.0.0-alfa ?

[ljharb]

That's up to you - there is no explicit semver contract between prereleases - but that's what i'd do, yes.

[kokushkin]

And so, do you agree that an initial development process involves much more breaking changes than, let's say, when a package in production use already? Not least because we don't feel obligated to support backward compatibility in full scale on such an early stage.
Therefore, when you've done with the initial development, you may end up with something like 1.0.0-alfa <... <123.2.3-beta < 123.2.3 . So your first production-ready version would be a much bigger number than it usually happens in other packages, is that ok?

[ljharb]

Yes, but in my experience, npm publish is something that's inappropriate to run during an initial development process :-)

and no, it'd be totally fine to publish a v1.0.0 after you had a v123.0.0-beta.

[kokushkin]

and no, it'd be totally fine to publish a v1.0.0 after you had a v123.0.0-beta.

I've looked it up
v1.0.0 < v123.0.0-beta , according to semver and two very popular packages
https://semver.org/#spec-item-9
https://www.npmjs.com/package/compare-versions
https://www.npmjs.com/package/semver

console.log(compare("123.0.0-beta", "1.0.0", ">")); // true
console.log(semver.gt('123.0.0-beta', '1.0.0')) // true

so it kind of doesn't make sense and even potentially would lead to a contradiction in the future

Yes, but in my experience, npm publish is something that's inappropriate to run during an initial development process :-)

Well, if publishing initial development releases is inappropriate , then alpha, beta are also inappropriate , isn't? Anyway I don't think it's possible to stop people from publishing stuff on any stage.

[WalkerCodeRanger]

@kokushkin you did not quote the relevant part of the semver.org spec

4. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Also, while the semver.org spec doesn't say this, it would be very strange to increment version 0.x.y to 0.x+1.y. It should be 0.x+1.0 since you normally set later versions to zero when incrementing.

[ljharb]

@WalkerCodeRanger thats v2 of the spec; node more closely follows v1, and in node, it works like this: X is major, Y is minor, Z is patch, and it’s either 0.0.X, 0.X.Y, or X.Y.Z.

[wraithgar]

Looks like the discussion answered this as well as it can be answered.