Release survey

[BridgeAR]

There are multiple different proposals how to change our LTS releases right now but without any consensus on what the best solution would be.

The current way for LTS releases is as follows

1. Current release handling:

   1. Active LTS (one semver-minor each three month and two patch releases afterwards with each a month in-between). Time frame: 18months
   2. Maintenance LTS (only patch releases and security releases each ...? month). Time frame: 12months
   3. The release branch is never rebased and following releases always contain the exact same commits as the former ones, just additional ones on top. The source of truth for the release is always the release tag.
   4. Total Release Time frame: 36months (first 6month current)
   5. Concerns:
      • LTS difficult to handle, time-consuming to audit each commit.
      • Prone to conflicts as we're not landing some, and landing some commits out of order.
      • Easily outdated
      • Progressively worse over time, more prone to conflicts etc.
      • After some time during Active LTS we get so far behind that we only backport major bugs and commits by request.
      • Backporting/fixing conflicts is error-prone
      • Landing out of order could change behaviour
      • Empty commits as we may land a subsequent commit that already includes the changes of a prior commit.

2. Proposal to change the time frame for active and maintenance LTS.

   1. Active LTS 18months ->12months, Maintenance 12months -> 18months A proposal for changes to LTS #458
   2. Pros:
      • Somewhat more reflective of what we're doing at the moment for v10.x. Already at the point where we're backporting major bugs and specific requests.
      • The incentive for people to move up to later release lines to use new features
   3. Cons:
      • The perception that some features will not be available in LTS release lines.
      • May harm people migrating and stop them from trying out new features on older release lines

3. Proposal to allow the release branch to be rebased for each semver-minor and to add a separate semver-patch branch for the patch releases. This prevents out of order commits and reduces conflicts but it's a bit more work to maintain both release branches (likely not a whole lot though). The source of truth for the release is always the release tag. Each release might contain different commits than the former release.

   1. Proposal to update staging branches #420
   2. Pros:
      • A more similar process for LTS and Current releases
      • Less conflicts
      • People would be able to backport SemVer minor commits closer to the point when it landed in a current release.
      • Possible to land all commits in order
   3. Cons:
      • Concern that we would lose metadata for the commit hashes that landed in the patch releases only.
      • Changing the order of commits could change behaviour (little bit cautious?)
   4. Instead of rebasing we could try to merge any clean minors ontop of the patch releases and compare whether this will cause more conflicts.
   5. Potentially trial this method with the 12 branch

4. Proposal to always create semver-minor releases and to stop doing any semver-patch releases to prevent out of order commits. This reduces conflicts and makes it easier for the release group.

   1. Proposal: Stop specifying patch or minor for LTS releases #449
   2. Pros:
      • Least out of order commits and conflicts
      • Features and fixes are brought back to LTS in a more timely manner
   3. Concerns:
      • Concern that minors are riskier than patches
      • Counterpoint: less likely to introduce bugs in existing features in a minor release.
      • Managed runtimes?

@nodejs/releasers please fill the gaps and add further information. This could than be used to create a survey with which we are able to gather feedback from our users what they believe would be best for them. If I missed a proposal, please just edit the description above.

[keywordnew]

The annual Web Survey is open for feedback for 2 more days.

nodejs/admin#380

Currently there are two questions relevant for this thread:

• Which release line of Node.js do you follow?
• On a scale of 1-10 where 1 is not important at all and 10 is extremely important, how important is it to you to have a Long Term Support Version (LTS) for Node.js?

[BethGriggs]

@BridgeAR, is this something you'd like to leave open for us to consider in future? We've not discussed it in a while.

[BridgeAR]

I am fine with closing this. If anyone wants to follow-up, please feel free to do so.