Revamping the LTS Schedule

[jasnell]

@nodejs/releasers @nodejs/tsc ... I'd like to kick off a discussion about potentially revamping our LTS support schedule. Currently we have 3 overlapping LTS branches in addition to current (10, 12, 14, and 15) not to mention the main dev branch. This has been an ongoing maintenance burden, especially when we encounter security issues that require coordinating releases across multiple branches.

I would like to propose and discuss a couple of alternative approaches:

Option 1: Shorten maintenance LTS to only 6 months.

In this option, an Active LTS branch would move to Maintenance in October and only be supported until the following April, giving a total LTS maintenance time of 18 months. This would reduce the maintenance burden but likely makes the support period too short for many enterprise customers.

Option 2: Move to a model that is closer to Ubuntu's approach

The short version here is this:

• Odd-numbered majors would continue only receiving 6-9 months of support as they are now.
• Even-numbered majors would be guaranteed 12 months of support.
• Every other even-numbered major would receive extended LTS support of at least 30 months.

Option 3: A more radical Canary/Fast/Slow Track model

Here we would move away from the current release model entirely and switch to tracks.

• Canary Track -- All changes landing in the main dev branch with releases every few weeks (stable + experimental + in development features)
• Fast Track -- Stable and selected experimental changes graduating from the Canary Track with releases once a month (off-schedule interim releases for security issues only)
• Slow Track -- Verified stable changes graduating from Fast Track with releases twice a year (off-schedule interim releases for security issues only)

This is a much more radical change that would have an impact on our semver policies. There are some definite advantages to this approach that could justify the disruption.

There are likely other options. Let's lay them out and discuss here.

[MylesBorins]

/cc @nodejs/lts

We did make a change to flip maintenance + active LTS... 12.x vs 14.x is the first time we are seeing this in practice. We should definitely revisit and consider modifying policy prior to 16.x moving to LTS, which give us ~1 year to figure this out.

While cutting all the security releases are a pain, it hasn't seemed to be a total bottle neck, especially since we now have many more releasers. Perhaps I am mistaken though and it is harder to get folks than it seems. Keeping the older releases lines having green CI + CITGM and maintaining the infrastructure seems like a much higher cost.

Another approach we could consider would be dropping maintenance from 18 months to 12 months. This would be slightly less radical than shortening to 6 months but would accomplish not having 3 LTS branches we need to release for at the same time.

I'd prefer taking this more conservative approach. although I do recognize that would mean it wouldn't be until April 2023 that we would start to reap the benefits.

[richardlau]

We did make a change to flip maintenance + active LTS... 12.x vs 14.x is the first time we are seeing this in practice. We should definitely revisit and consider modifying policy prior to 16.x moving to LTS, which give us ~1 year to figure this out.

In my opinion it's still too early to tell what the effect of shortening the active maintenance period for 12.x plus the extra onboarded releasers will have on regular (i.e. non-security) releases.

While cutting all the security releases are a pain, it hasn't seemed to be a total bottle neck, especially since we now have many more releasers. Perhaps I am mistaken though and it is harder to get folks than it seems. Keeping the older releases lines having green CI + CITGM and maintaining the infrastructure seems like a much higher cost.

My experience of the last two security releases is that the bottlenecks are the preparation of the pull requests to fix the security issue(s) and not the release mechanics. We have understandably kept the number of people with access to prepare the security fixes to a small number of people but that does put time pressures on them to get the fixes ready so that we can announce the expected date for the security release. With the first security release I was involved in we were only aware that one of the fixes didn't pass CI once we locked the CI down which led to a scramble to try to get that into a releasable state.

Another approach we could consider would be dropping maintenance from 18 months to 12 months. This would be slightly less radical than shortening to 6 months but would accomplish not having 3 LTS branches we need to release for at the same time.

I'd prefer taking this more conservative approach. although I do recognize that would mean it wouldn't be until April 2023 that we would start to reap the benefits.

+1 for a conservative approach. I'd be reluctant to shorten the overall LTS lifetime (I am open to adjusting the active vs maintenance periods but would prefer to wait to see how the last adjustment plays out). When I worked for IBM one of the challenges was that the 30 month LTS period was already shorter than the typical support cycles for enterprise software (at least in IBM).

[cjihrig]

When I worked for IBM one of the challenges was that the 30 month LTS period was already shorter than the typical support cycles for enterprise software (at least in IBM).

FWIW, I've also heard numerous complaints that the current LTS period was too short.

[mhdawson]

My initial take is that the current 30 months support is already a bit short for some users. For that reason of the options listed I prefer option 2.

For users that need a longer time period we retain the 30 months of support and they should be ok with an extended LTS every 2 years as they are only going to upgrade less frequently anyway.

For users that want more up to date versions, they still get a release every year, and since they want more up to date releases they should be ok with the shorter 12 months of support.

It seems like an approach that would help us cut down on concurrent release streams at the same time as not impacting the users with different needs in terms of the balance between length of support/need for latest features.

[sxa]

@mhdawson Suggest adjusting "extended TLS every 2 years" to "extended LTS every 2 years" in case people try to interpret this as a statement about how we incorporate OpenSSL :-)

[mhdawson]

Done

[sxa]

I'd probably lean towards option 2, however I'd also ask to the question as to how many users would object if the alternate "12-month LTS" was just another normal one i.e. do LTS every 2 years. Do we know how many enterprise customers are actively moving up to each one as opposed to skipping at the moment? Are many non-enterprise users actively choosing the LTS ones?

For comparison, java's currently policy is a new major release every six months (latest one being 15 like Node.js) but only have an LTS every 3 years (so every 6 ... Rather oddly that means the 11, 17, 23, 29 LTS releases are all prime numbers but I think 2 years would be the maximum we'd want for Node)

[MylesBorins]

We should reach out to some of the vendors who provide cloud services for Node.js about these decisions. I know that the various serverless platforms have opinions

[danielleadams]

I need to check, but I think I can pull some numbers from Heroku regarding how many applications and builds we are running with each major version. I'll get back to y'all.

[mhdawson]

One piece of feedback I got on option 2) is that the 12 months of support is that is does not give any overlap in terms of customer being able to test/update to LTS before the earlier version is out of support.

[meadowsys]

I want to propose a schedule. There are new releases every 6 months (same as right now). Every major release gets an active/maintenance LTS for 6 months after the next release is released. Every fourth(?) major release gets an active and a longer maintenance LTS (45-60 months?) that will overlap slightly with the next long maintenance LTS release starts (time for migration).