Change MUST reset to SHOULD reset

[sgryphon]

As this is relaxing a constraint, it would be a minor update (2.1) to the specification - all existing implementations would remain compliant.

The relaxation of the increment by 1 requirements from SemVer 1.0 allowed, where it was necessary, to skip an increment, e.g. from release 2.4.10, change to 2.6.0 (or 4.0.0).

But, as the specification currently stands it would not be possible change from 2.4.10 to 2.5.1 - it MUST be 2.5.0 (or 2.6.0, etc).

Changing from MUST to SHOULD still encourages the reset, but allows for situations where it is not followed.

Example, moving from version 2.4.10, there could be an extensive period of 3.0.0-beta.1, 3.0.0-beta.2, etc, that never actually gets released, but is widely known; if the decision is made to skip a version, then this change would allow 3.1.0 to be developed (releasing 3.1.0-beta.1, etc) and eventually released (as 3.1.0). Without this change, the only option would be to bump to 4.0.0.

[sgryphon]

Also note that allowing this does not change the semantic interpretation or usage of versions, which is the aim of the standard.

e.g. if Firetruck requires Ladder 3.1.0, then Ladder 3.2.1 can be correctly interpreted as being compatible, even if 3.2.0 was never released (not currently allowed by spec), the same that 3.3.0 can be correctly interpreted as being compatible even if 3.2.0 was never released (which is allowed under the current specification).

[jwdonahue]

@sgryphon, what is the problem with this scenario?

master
2.3.10 // Released.
2.5.0-a.dev.internal // Start new sprint for major release.
3.0.0-alpha // Dies in ring zero flight testing.
3.0.1-alpha // Ships to external early adoptors.
3.0.2-beta // Ships.
3.1.3-beta // Ships, marketing insisted on one late feature.
3.1.4-beta // Ships.
3.1.5-release.candidate1 // Does not ship (test lab caught fire!).
3.1.6-release.candidate2 // Ships, most customers love it.
3.1.7-release.candidate3 // Ship fix for your big partner's special corner case.
3.1.1 // Released.
3.1.2-a.dev.internal. // Start new sprint to pay back technical debt.
etc.

While there is a prerelease tag on the version string, any point release can break anything, the interface/package is unstable. Incrementing the patch number for all internal/external builds helps retain provenance tracking back to the 2.4.10 release and provides strong ordering, leaving considerable leeway in what you put into your prerelease tags, but given the above prerelease tags, you could just as easily leave the triple pinned at 3.0.0 for the entire sprint.

I don't see how anything in the spec precludes the above and it achieves what I think you are after without modifying the spec. Do you see any problems with it?

[FichteFoll]

Could you elaborate on the part that causes "3.0.0" to never be released? Is this a marketing question?

You may pull releases in case they are erroneous, in which case a version hole would ensure, but I don't see any reason to skip a version altogether.

[jwdonahue]

@FichteFoll, I can list a few, yes, but I am sure the number of reasons I don't know why, might as well be infinitely larger. For all intensive purposes, a version 3.0.0 that was released and then removed before anyone downloaded it, is essentially a missing version. SemVer constrains the number of dev-ops processes that lead to a correct implementation of the standard, to a smaller infinity than the non-adherence-to-the-standard set, but it should not, in my view constrain that good set anymore than is absolutely essential. Requiring any x.0.0 release is not practical, especially in light of the admission that any version can be withdrawn at any time.

The primary reason I think the above scenario MUST be allowed, is that the semantics of words used in the prerelease tags does not always sort lexicographically the way that alpha and beta just happen to do, and prefixing additional numeric or alpha fields to achieve this, just adds cognitive load to human consumers. You can find instances in my issues responses and other places where I have probably used the -a.dev tag in order to insure that all *dev prereleases sort below -alpha. The other work-around for this limitation is to always bump something in the SemVer triple, which is the primary point of the example scenario.

Basically, all "prereleases" should have a prerelease tag on them, and if you intend to use full semantic versioning through the entire prerelease phase in order to give early adopters and testers a clue, then you could very well run right past 2.x.x and 3.0.x on your way to the 3.3.1 release, while actually publishing prerelease versions of them. Yes, marketing will have some influence on the final decision of which version to actually "release", but so will QA and probably division leads and CEO's as well.

[jwdonahue]

Prerelease is a misnomer in the standard that comes from common practices. We publish/release a version of something under the caveat that it is not the promised release that is yet to arrive. Maybe we hope that 3.0.0-Final.Beta will result in a 3.0.0 release, but we fail to do so due to marketing forces that suddenly require us to adhere to some recently adopted standard and we wind up releasing 3.1.x instead.

[jwdonahue]

Even if never releasing an X.0.0 is a violation of a strict reading of the standard, I am not aware of any case where failing to do so, breaks anything, therefore it is a restriction I can easily ignore.

[sgryphon]

@jwdonahue I guess pre-release would be a way to conform to the exact spec, and there is no way for anyone to ever know that those missing releases didn't exist.

According to the spec, the minor version MUST be reset. This could be applied internally to a non-released version, so the following sequence is valid:

2.201712.10 // Released
3.0.0-internal // Internal release with minor version reset, to satisfy the specification
3.201801.0 // Released; the actual release number you want, for some unknown reason

But the following would be technically non-conforming (but does not break any semantics):

2.201712.10 // Released
3.201801.0 // Released

i.e. you nver produced an internal pre-release with 3.0.0, although there is no way for anyone to ever know this.

Changing the wording from MUST to SHOULD would simply make this official. I don't think it would break anything.

[jwdonahue]

@sgryphon , what tooling are you using for packaging and publishing?

[grv87]

I don't see in the current version of SemVer any notice that release should be public (non-internal). So, situation described by @sgryphon is perfectly legal now, no need to change anything.

[jwdonahue]

@sgryphon, take a look at VersionMeta and VersionSchema. Please let me know what you think.

[jwdonahue]

For whatever it's worth, I vote to reject this change. It's the wrong solution for @sgryphon stated problem. If anything, we need to make it clearer what it means to "release" something and the fact that the a publisher is under no obligation to officially release any X.0.0 version. Any X.y.z is fine, as long as X > 0, eventually.

[KyLeggiero]

The spirit of resetting to 0 is what you're talking about. It means that you mustn't go from 2.4.10 to 3.4.10, or 2.4.10 to 2.5.10. You're describing someone following the proper guidance as described today, so no change is necessary.

[alexandrtovmach]

Closing & re-opening to trigger CI

[Nidacoke]

How can I do everyone any idea