Handling LTS and version sequencing

[robertalanpower]

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]

"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]

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]

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]

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.