Discussion: LTS Proposal

[rvagg]

See https://github.com/nodejs/LTS/#proposed-lts for the current proposal and leave feedback here. This is effectively a continuation of #8 but we now have a concrete proposal.

[ryanstevens]

I'm a little confused on the details of around versioning active LTS releases

semver-major bumps are permitted between LTS releases.

Does this mean the active LTS version can do a release that bumps semver-major?

Note that while it is possible that critical security and bug fixes may lead to semver-major changes landing within an LTS stream, such situations will be rare and will land as semver-minor bumps.

Not exactly sure how to interpret this, but is this trying to say critical security and bug fixes might introduce breaking changes, but instead of following semver they will be released as backwards compatible (minor) version bumps?

The implication of this is that the semver-major bump should be timed to roughly coincide with the regular yearly LTS release schedule.

I think it could be good to explicitly state upfront something to the effect of "The purpose of LTS is to limit the breaking changes of Node for 12 months". It's not actually stated anywhere why someone should care about LTS, and the above quoted line only implies this statement (if it's even true, I might be interpreting this line totally wrong).

[jasnell]

Does this mean the active LTS version can do a release that bumps semver-major?

No, it means that semver-major bumps can occur in next or master between LTS releases; the effect is that an LTS release one year would be one or more major versions higher than the previous years LTS.

Not exactly sure how to interpret this, but is this trying to say critical security and bug fixes might introduce breaking changes, but instead of following semver they will be released as backwards compatible (minor) version bumps?

Yes, that's exactly what it's saying. The LTS will be cut on the last major.minor in master before a semver-major bump. Within that LTS, semver-major changes need to be avoided but unfortunately may be necessary to deal with a critical security issue. However, because there is a single version shared across next, master and LTS releases, the LTS release cannot bump majors without stepping on next and master. So the only other option would be to either (a) introduce some additional out-of-band versioning metadata for LTS releases (i.e. build metadata extensions) or (b) use separate versioning for next/master/LTS which would just end up leading to more confusion. The LTS WG felt that this divergence from strict semver rules isn't great but it's likely the best solution. If such breaking changes are made, they would be documented in the release notes for the updated LTS release.

I think it could be good to explicitly state upfront something to the effect of "The purpose of LTS is to limit the breaking changes of Node for 12 months"

Yes, I plan to add a more "reader-friendly" tl/dr section that expands on this.

[geek]

Once a release moves into Maintenance mode, only critical bugs, critical security fixes, and documentation updates will be permitted.

We should be clear on the rating system and what types of bugs and security issues are deemed critical. In my mind, any security bug should be patched, so we should be clear on what constitutes being critical.

[rvagg]

@geek do you have a suggestion for wording here? I agree with you but am struggling to come up with suggestions for how to differentiate "critical" here when we also have to decide on the backporting threshold for standard LTS. Basically we have two ill-defined thresholds.

[geek]

Sure, maybe we follow a rating system like https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology and just link to that?

[mhdawson]

CVE's include a severity level (ex see https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-5380) maybe we can use that as an objective thresh hold. ie if base score is >X .