mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #811] Handling LTS and version sequencing #5648
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#5648
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 @robertalanpower on GitHub (Mar 3, 2022).
Original GitHub issue: https://github.com/semver/semver/issues/811
Here's a scenario we're looking at:
Time 0: 7.1.0 - designated as an LTS release ; meaning critical bug fixes and security patches only
Time 1: 7.1.1 - critical bug fix; no new features
Time 2: 7.2.0 - significant new features added in a compatible way
Time 3: 7.x.y - customers using 7.1.x LTS stream finds a security issue requiring new functionality;
What version would I use for the patch at Time 3? I can't use 7.1.2 since that would break semver rule #6. But, 7.3.0 is problematic since it does not contain everything in 7.2.0.
Can someone clarify how this would be handled in semver?
@ljharb commented on GitHub (Mar 3, 2022):
"release streams" are not part of semver; "LTS" has no meaning here.
In your case, you'd presumably first fix the problem in v7.2.1, and then publish a v7.1.2 that consisted of v7.1.1, plus only patch-level changes (this is called a "backport"). In npm, you do this by specifying (for v7.1.2) a dist-tag that isn't "latest".
Semver doesn't dictate chronology, only changes between two versions. You can publish a v1.0.1 any time you like, as long as relative to v1.0.0, there's only patch-level changes.
@robertalanpower commented on GitHub (Mar 3, 2022):
Thanks for the quick reply!
You are correct that we would probably first fix the problem in v7.2.1 and then backport the change. However, the concern is that the fix does not contain only patch level changes since it requires new functionality in order to fix. So, I thought it would require a minor version increment rather than a patch version increment. Our solution to this problem to date has been to do exactly what you suggest (v7.1.2) but its been commented that this is not in accordance with semver.
When you say "release streams" are not part of semver, do you mean it just doesn't handle this situation?
Thanks
@ljharb commented on GitHub (Mar 3, 2022):
If it requires new functionality to fix, then you can't do it in a v7.1.x - which is why LTS streams aren't usually confined to sticking to the same minor version.
I mean that the concept of "release streams" is outside of semver, and thus using them will create situations like this one.
Probably the easiest thing is to designate v7.2.1 as the latest version in the LTS release stream.
@robertalanpower commented on GitHub (Mar 7, 2022):
Thanks, I think the root of our issue is that we need release streams due to customer commitments and they are outside of semver so it creates these types of situations. Appreciate the timely feedback.