Repository navigation
Proposal: Stop specifying patch or minor for LTS releases #449
Description
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
Activity
MylesBorins commentedon May 31, 2019
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 commentedon Jun 2, 2019
@MylesBorins
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 commentedon Jun 3, 2019
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.
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 commentedon Aug 29, 2019
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.
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 commentedon Aug 29, 2019
I think this is kind of what happens when we can't keep up anyway.
MylesBorins commentedon Aug 29, 2019
@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 commentedon Aug 30, 2019
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 commentedon Mar 9, 2020
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.