mirror of
https://github.com/semver/semver.git
synced 2026-07-11 04:52:47 -05:00
[GH-ISSUE #773] Additional version increments #7486
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#7486
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 @cobusve on GitHub (Nov 26, 2021).
Original GitHub issue: https://github.com/semver/semver/issues/773
There are some cases where we would like to update major or minor version numbers without having necessarily changed any code.
One example is providing a long term support (LTS) version, in this case we want to really fork our development stream.
As an example lets say we are at version 10.4.3 and we want to now offer long term support on this. It seems to make sense to release the LTS version as 10.5.0 to allow us to use 10.5.1 as a patch version if a critical bug fix is required for the LTS version. At this time we would have to release our next non-critical patch as 10.6.0. If we did not do this a non-critical bug which is not appropriate for the LTS version would end up at 10.5.1 leaving us in an awkward position later when we need to make a critical patch to the LTS version.
I understand that semantically you want to say a minor version update changed AT MOST the addition of backwards compatible functionality. It however seems reasonable that I could increment the minor version number when I need the development stream to fork without adding new functionality without violating the semantics of compatibility. Am I correct in this assumption?
So my question is this, is it within the specification to interpret the minor versioning increment requirement "It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes." as "It MAY include ONLY patch level changes" ?
@cobusve commented on GitHub (Nov 26, 2021):
Just for completeness - of course in the example above we COULD declare the stream 10.4.3 to be the LTS stream and release the next patch as 10.5.0, leaving the 10.4.x stream for patching LTS while normal development patches will live in 10.5.x, thus avoiding an additional minor version update ...
@ljharb commented on GitHub (Nov 26, 2021):
LTS status is entirely independent of version numbers, which only convey breakage.
node, for example, starts a release line as LTS at whatever version it happens to be on.
@jwdonahue commented on GitHub (Dec 4, 2021):
Taking your questions in reverse order:
I believe you are referencing the spec paragraph #7. The answer to your question is YES. It also means it MAY not include ANY patch level changes. As long as you don't try to enforce "It MUST only include patch level changes", then your interpretation falls within the spec, IMO. In fact, you could randomly bump any of the version numbers at any time, provided you don't violate any of the SemVer constraints.
And that brings us to the first question:
Yes.
The wording of the spec is loose for good reason. That's why it is so widely adopted. Your intuition that you can use the minor version number to create patchable forks is accurate. You can also do the same with the major version. There's no SemVer requirement that 1.0.0 leads to 2.0.0, etc., but that is the most common of the version histories you'll find out there. You just have to consider how your consumers are supposed to interpret your version histories.
As a consumer, I see 4.5 as greater than and compatible with 4.1. There's nothing in the SemVer spec that touches on labels like LTS or LKG. Tooling drives automation, so your customers will tend to migrate away from an LTS version 4.5.z to your non-LTS version 4.6, which might contain some experimental feature(s) you may or may not be committed to yet (though these should have prerelease tags on them). So maybe it makes sense to drive a stake in the ground at say 4.5 for an LTS, while you play around with the speculative 4.[1..4] series? Driving adoption of 4.y's features will require some special effort and probably confuse a lot of people.
Consider attaching pre/postfix tags to the product name and using the full SemVer to version those. Given the choice, the maintainers of mission critical systems won't mind using Retro-LTS 1.3.7, while their developers work the vNext product against Retro-Next 1.0.99 (assuming vNext is aiming for compatibility). Alternatively, some tool chains support attachment of moveable labels to specific versions of packages in their feed. If your tool chain supports that, then there's a side-channel signal for risk averse systems maintainers to use, to avoid letting the SemVer state machine drive them into ruin.
My personal preference of late, is to use the Major.YYYYMM.DD.Build# scheme, where a change in the Major field is a breaking change and the rest should be self explanatory. You can even add immutable and/or moveable tags to those, but there's not a lot of OTS tooling available for that.
@cobusve commented on GitHub (Dec 13, 2021):
The 2 comments above exactly match my expectations here, I was hoping to get some kind of authoritative answer by logging an issue here, would that be possible?
@jwdonahue commented on GitHub (Dec 13, 2021):
The specification is the authority here. It says what you must do under a limited set of conditions and is mute on everything else. All other content are the opinions of their respective authors.