mirror of
https://github.com/semver/semver.git
synced 2026-07-11 04:52:47 -05:00
[GH-ISSUE #484] Decrement is undefined #2091
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#2091
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @KyNorthstar on GitHub (Jan 7, 2019).
Original GitHub issue: https://github.com/semver/semver/issues/484
Decrementing any of the three version numbers is not discouraged, encouraged, nor defined at all. I assume that it's a MUST NOT. However, I could imagine a situation in which, like incrementing, when one version number changes, any less-significant ones are reset to 0. So
1.2.4becomes1.1.0.I would not ever decrement a version number, and think it should be called out in the spec in some way.
@rodmar77 commented on GitHub (Jan 8, 2019):
"A normal version number MUST take the form X.Y.Z (...) . Each element MUST increase numerically. For instance:
1.9.0->1.10.0->1.11.0." How is that not defined? Saying it MUST increase numerically is the same as saying it MUST NOT stay the same or decrease numerically.@KyNorthstar commented on GitHub (Jan 19, 2019):
I read that as how it must increase, not that it must increase, and so that it must not decrease is... At best implied
@runeimp commented on GitHub (Jan 19, 2019):
I think it's a bit nit picky but explicit is better than implicit.
@rodmar77 commented on GitHub (Jan 21, 2019):
I think it is explicit, though. Notice that there is no emphasis on 'numerically', meaning ONLY that this is the way it increases; it states that it MUST 'increase numerically', meaning that not only it must increase, but that it must increase numerically. Either way, I'm not sure how you can, from that text, understand that it would be ok to decrement numerically (or even maintain the same numbering) from one version to the next.
@jwdonahue commented on GitHub (Feb 19, 2019):
There is nothing in the spec that defines the order of public appearance of any versions. There's a loosely defined dichotomy in the spec, between publishers of artifacts using SemVer and consumers of artifacts using SemVer. In addition, the spec doesn't speak to most implementation details. If you think about it, a compliant tool/function that generates SemVerNext(productName), must increment one of the Major, Minor or Patch fields, but the spec doesn't say by how much. It doesn't reference how a producers product finds its way to the consumer. It certainly doesn't prohibit an arbitrary version A appearing some time after a version B (where A < B). There's nothing that says SemVerNextInRange(x, y, productName) would be an invalid function where SemVerNext(productName) leaves sufficient gaps.
The availability of a version X or X+1 is not within the scope of the SemVer spec. These are tooling and producer process details that have not been within the scope of SemVer. They probably shouldn't ever be considered within its scope. Think about the following version history:
1.0.0 // First release.
1.1.0 // First new feature added.
1.0.1 // Bug fix for 1.0.x
Technically, 1.0.1 is less than 1.1.0, but this is quite legal as far as the SemVer spec is concerned. The above appears chronologically in the order specified, but SemVer sort ordering rearranges them. A given feed/channel might have every version ever released for a product one day an arbitrary fraction of them some other day. From the consumer's perspective, they may come and go and come back again. The online services that provide such feeds/channels are often distributed and unreliable, but the owners may also have their own reasons for removing a version one day and making it available again the next.
The whole point of the version triple is that it allows you to issue bug fixes and new features on "down-level" versions of your products. The spec requires producers to increment a field, not the whole version number, but that's in reference to the producer, not the consumer. The consumer might see any random permutation of the producers version history. It's up to the tooling to use the precedence ordering specified by the spec, to determine what an acceptable up/down-grade would be, given the consumer's current version.
The spec forbids any two packages/interfaces or whatever else is being versioned, from having the same version number. That is, for any version X.Y.Z, there can only be one ordered set of bits.
It's arguably legal, to increment by 5 or 10 and then go back and back-fill the vacancies, but it's probably NOT what you want to do in most cases. The order of precedence rules specify how a list of versions should be sorted, and we use that sort ordering to decide which version to up/down-grade to. So if a publisher chooses to issue 1.0.5, then 1.0.4, they must take into account how their customers will tooling will behave. Perhaps internally, they developed them in the 1.0.4 to 1.0.5 order, but withheld 1.0.4 for legal reasons. Their build tooling is too rigid to back it out so they produce a stop-gap 1.0.5. Maybe they pull 1.0.5 from their feed/channel when they release 1.0.4, knowing that most of their customers are still somewhere below 1.0.3? Then maybe clean-up the mess with a roll-up fix at 1.0.6 as soon as they can get around to it?
My point here is that the spec is not intended to be so rigid that thinking persons can't do whatever needs to be done, within reason. We get complex emergent properties from the application of some very simple rules. Never say never, doesn't quite apply here though. Never release two different ordered sets of bits as the same version number. Never violate the explicit rules specified in the SemVer spec and just about everything else you can do is implicit.
How can a consumer tell the difference between 1.2.0, 1.1.0? They can't. Their tooling will sort them into 1.1.0, 1.2.0. Different consumers will witness different histories.
I would add that all of the packaging tools I am aware of, allow their users to specify arbitrary version numbers for good reason. It's demanded of them by their customers.
@Bachsau commented on GitHub (Mar 29, 2019):
Of course any less-significant ones are ment to be reset to zero whenever a more significant number increases. This is clearly stated on Lines 87 and 91 of the document. If every part would just increase on its own, "Major" and "Minor" would be effectively useless. The whole point of semantic versioning is, of course, to be semantic. Common sense says that bugfixes won't be undone before release of a new minor version, and every change to that version increases its very own patch level. If not, you would end up with extremely huge numbers for no benefit in semantic logic.
@ljharb commented on GitHub (Mar 29, 2019):
I backport bugfixes to previous major lines all the time; any part can increase in its own at any time in any order, the only thing that’s constrained is the API delta between the new version and a previous one (in numerical, not chronological, order) which in turns constrains which numbers can increase and how (relative to the base version, unrelated to publish time)
@jwdonahue commented on GitHub (Mar 31, 2019):
Why is this issue still open?
@isaacs commented on GitHub (Apr 30, 2019):
A "decrement" is typically an increment to an older version release. It almost never makes sense to truly "decrement" a version of a piece of software (in the sense that
1.1.0comes after1.2.0in the git history), but may make sense to post a new update on a version train branch (so1.1.1is added to a branch forked off the mainline source control history at the1.1.0point, even thought1.2.0has already been published).See #504.