Proposal: Stop specifying patch or minor for LTS releases

[BethGriggs]

At the Collaborator Summit Release working group meeting, we discussed the potential of following the current release process for releasing minors/patches - where we do not plan in advance whether the release will be minor or patch. The main driver for this was to reduce the number of commits that land out of order, and therefore hopefully reduce the number of conflicts. The result of this may be that we end up releasing more semver-minor releases.

//cc @nodejs/releasers

[MylesBorins]

Some historical context. Originally the cadence was decided to avoid constant Semver-Minors. Teams tend to upgrade Semver-Minor LTS releases much slower, this tends to be especially acute for managed runtimes.

As we generally do Semver-Minor releases for Current (see 12.x for example) I don't see how we would be able to ever do a Semver-Patch for LTS if we took this approach.

To be clear, I definitely think we should dig in and discuss this.

[BridgeAR]

@MylesBorins

I don't see how we would be able to ever do a Semver-Patch for LTS if we took this approach

It would likely be rare but security releases and some important bug fixes would still be Semver-Patch releases.

We could use #420 instead which would also drastically reduce the number of conflicts in most cases, even for LTS but the semver-minor releases would be a lot bigger that way (I'll update the PR soon to iterate over it further).

Do we actually have some data about our users?

[sam-github]

I think that out-order landing of minors and patches on LTS made sense at the time, but that it has gotten more difficult with time, and we should move to in-order landing of commits on all supported branches.

Landing commits out of order in order to slow down the rate of semver-minors may (or may not, we don't have much data) be something some users are in favour of, but they might not be aware of the cost. I don't think we were aware of the long-term effect when the LTS program started. At the start, node had a long history of VERY stable low-frequency releases. IIRC, even features weren't backported very often, so the idea of backporting semver-minors to a stable release line was something people considered only with a lot of trepidation, and promising to slow down semver-minor releases was comforting.

We are a couple years later in the process, and I think we do have some data now.

1. LTS has been wildly successful, lots of people use them exclusively in production, and I'm hard-pressed to remember anyone thinking Node.js LTS stability has gotten worse since the LTS release time started managing the stable release lines.
2. People really appreciate getting semver-minors backported. Writing code that works across all currently supported release lines is much, much easier if they have equivalent features. For package maintenance, we are trying to get npm package authors to better support LTS lines. This will be easier with more feature parity (though semver-majors are obviously impossibly, they usually affect only very isolated use cases, we don't make sweeping breakages to node.js).
3. There aren't regular bugs introduced in the stable lines, and additive changes (like semver-minors) have been found to be less likely to cause regressions in existing features (since in theory, they don't change them at all) than patch changes (which by definition make a change to an existing feature, though bug fixes are usually changes people want).
4. The longer its done, the harder and harder it gets to land anything on older LTS releases, and so the flow rate of patches AND minors slows with time, to the point that 10.x is in a practical sense edging out of "active" and into "maintenance" prematurely.

Even people who like the concept of periodic semver-minors probably don't want them at the price of LTS branches going out of active maintenance early.

[MylesBorins]

Some thoughts

Commits will always have to land out of order. The idea that there is even an "order" is mis-categorizing the situation. The second a Semver-Major lands upstream that we are not backporting things are no longer landing in pristine order. The second we have to augment a commit because there is a conflict there is no longer a pristine order. The second a Semver-Minor or Semver-Patch is deemed to not be backportable there is no longer a pristine order.

Landing commits out of order in order to slow down the rate of semver-minors

This is not an accurate depiction of the process or why it was designed. We backport what we can to ensure that branches are moving forward and that known issues can be fixed.

I think that there is a reasonable premise here, attempting to make the LTS process faster / easier... but I do not believe that this solution will accomplish that. Further I think that if we moved to a world where most LTS releases were Semver-Minor we would be undermining the process itself and hurt adoption of LTS.

It has been my experience that larger enterprise teams and cloud service providers are slower to adopt Semver-Minor releases than they are Semver-Patch. The regular cadence of Semver-Minors makes it significantly easier for these teams to plan the update process.

I geniunely believe that there are ways we can improve the LTS process... but my gut feeling is that creating more constraints, which this proposed process does, will not help improve our velocity. An alternative solution would be to no longer audit and backport all commits, but rather only backport commits that are requested.

[mhdawson]

An alternative solution would be to no longer audit and backport all commits, but rather only backport commits that are requested.

I think this is kind of what happens when we can't keep up anyway.

[MylesBorins]

@mhdawson one thing I've been thinking for a while is that the way we do LTS and releases at large is not super sustainable. We need more people in the main project to be actively involved in the process not relying on a small subset of maintainers.

If official policy is asking for requests then perhaps upstream will make more of an effort in tagging issues.

That was the original process @jasnell proposed in 2015 / 2016. I ended up going through and manually auditing EVERYTHING because of a fear of missing commits or things landing in an unexpected way... which is kind of the main thing this proposal is attempting to fix.

[mhdawson]

I think the argument against the "based on request" is that ends up being harder to land patches if not all of the earlier ones have landed. But it's still turned out to be a lot of work and hard to achive making it easy to land patches anywayt. I agree that we need more people in the main project involved and maybe we are ready to try out doing "on request" for a release to see how that goes. Doing that for 13 (Current not going to LTS) might be a good candidate to try it out.

[BethGriggs]

I think this can be closed as I don't think we're actively considering changing our approach. I think #458 has (and will?) help with the conflicts/backport-requested-x backlog as there'll only ever be one Active LTS release at a time.