Proposal for new release schedule / users are not interested in releases that will not become LTS

[mcollina]

I took some time to create an small web app that render the Node.js Downloads data from the CDN, aggregating them by months:

https://nodedownloads.nodeland.dev/

(Code at https://github.com/mcollina/nodejs-download-stats. I will put this under a proper domain as soon as I get back).

The download numbers show that very few people are downloading the releases that are not going to become LTS. This is matched by anecdotal feedback from collaborators that bugs are not reported for releases that are not going to become LTS.

What people expect from LTS is our "maintenance" phase, and they also expect our "active" LTS to land new features regularly.

Therefore, I propose a simplification to our LTS process:

1. Stop doing all releases that are not going to become LTS
2. eliminate the "current" phase
3. increase the "active" LTS phase to 1 year.

For example, we would cut v22 in April 2024, which would stay "active" LTS until April 2025, when we will ship v23. v22 will go into "maintenance" LTS at that point.

This has the benefit of simplifying our messaging to:

• if you want new features, stay on active LTS
• if you want to avoid surprises, stay on maintenance LTS
• as a maintainer, you should add support to all releases (right now quite a few people skip non-LTS releases)

We should also consider an increase of the length of the maintenance phase, if possible by our dependencies.

(Thanks to @qard for the review)

[aduh95]

That would mean that we can ship semver-major changes every year, instead of every 6 months. For example, today a full deprecation cycle can take a minimum of 1 year. With this proposal, the minimal would be 2 years.

It’d also mean more errors will slip through to end-users.

I’m not sure our current messaging is confusing, I’d argue that the graph you shared on the contrary shows that everyone understands actually quite well our release cycle.

[lifeisfoo]

The download numbers show that very few people are downloading the releases that are not going to become LTS

If you look at the first six months after each release you can see that the download rate is similar between LTS and non-LTS releases. When a new LTS is released, the previous non-LTS release downloads decrease quickly - as expected. The same pattern is visible here.

As a user, I use non-LTS versions to test my existing applications: in this way, the migration to the next LTS will be easier.

[BethGriggs]

Agree with @aduh95.

This is matched by anecdotal feedback from collaborators that bugs are not reported for releases that are not going to become LTS.

Wouldn't this proposal mean we'd potentially have semver major changes sitting on the main branch unreleased for up to almost 1 year? I feel that could become difficult, and would result in even less feedback (as we get very few users of nightly and rc builds) and therefore more surprises. I do think we still get value from the alternating LTS/Current releases as we have a chance to land riskier breaking changes in an odd release giving us a window before the project is committed to supporting it long-term.

Generally, I feel the benefits of adjusting the release policy and schedule need to be quite high for it to outweigh the disruption and unlearning required by consumers and end users. It would be good to frame what problem we're trying to solve for end users before jumping ahead to restructuring the policy and schedule.

[benjamingr]

For the change to make sense to me we need to address deprecation cycles and semver-major changes. If the release plan can be adjusted while keeping those at an as-good or better cadence -I'm for it.

[mcollina]

My understanding from the session we had at NodeConf.eu was that very little feedback is provided by the non-LTS releases, with bugs introduced there got reported way in the following release. From what we have seen recently, quite a few bugs are reported only until a release is flagged as LTS (which then include a long cycle for updates).

This is the starting point of this discussion, and the download data seems to back it up, as odd releases have minimal downloads.

[Qard]

Yeah, our own data shows users basically never install odd releases, so they're kind of superfluous. We're just adding extra complication to the release cycle by doing them.

[BethGriggs]

I think we should take into account that download data will be made up of a significant number of automated builds and deployments which, based on recommendations, target LTS over current. There were 155,314 downloads of v21.1.0 on 8th November- I wouldn't consider that an insignificant number for one day even though there is a huge relative difference to LTS.

[benjamingr]

My understanding from the session we had at NodeConf.eu was that very little feedback is provided by the non-LTS releases,

We have a concrete recent counter-example with navigator

[targos]

We have data from production deployments

That's highly biased. We don't expect many people to use odd versions in production. It doesn't mean they won't use it in CI. Also, open source libraries can run their tests on odd versions.

[gurgunday]

That's highly biased. We don't expect many people to use odd versions in production. It doesn't mean they won't use it in CI.

Ok, but what would be the difference between running CI on a more recent version of node that practically never gets deployed to production and just running it on main (or an active LTS in the proposed plan)?

Apart from maybe having more CI breakages that don't affect any real user, I can't see it

Even if it was granted that testing on a proper interim release is better, after a non-LTS release, the next one that would become the LTS is again a major bump, which has its own breaking changes and bugs (i.e. node 20)

So for instance I'm not sure if anything concrete got accomplished by testing on node 19

No opinions, just providing perspective

[Qard]

As far as I can tell odd versions are only ever used in CI because we've trained people to think people might actually be using those versions in production. But no one actually does so it's really just a slightly more stable equivalent of nightly for the use case--catch when new things in Node.js break the code--which the proposed model would equally cover.

[targos]

It's not the same as using a nightly. My default version currently is 21. I would not bother always updating to the latest nightly.

[ljharb]

node is also not exclusively used “in a production server environment”. It’s used for scripts and automated tasks and on embedded devices and many other things where LTS status may not be relevant.

[Qard]

Agreed, though I don't feel like this proposal worsens the experience of those non production server use cases in any way that I can see. I think generally less complex interacting rules the better from a user clarity perspective. I've seen plenty of confusion around why LTS is every other major and why it doesn't start at x.0.0 releases. I'd opt for the path of least confusion here.

[ljharb]

Worth noting that nvm, and many other version managers, may have to do a fourth (0.x → iojs → LTS) significant change to how versions, aliases, and release lines are tracked, depending on how the changes are made.

If the decision ends up being to make a change, I would welcome the opportunity to help ensure it's an easy transition.

[mhdawson]

I think the 6 months of a new release being "Current" before it is promoted to LTS has helped us in the past with respect to catching/fixing problems before the release is LTS. I think it helped with an issue related to APM/loaders for 20.x and @benjamingr mentioned the example of navigator above for 21.X

[mhdawson]

I think we should remove this from the TSC agenda and drive this as a discussion within the Release team until we have a proposal from the Release team for any changes that make sense to them. I think @RafaelGSS had volunteered to lead that discussion and bring the discussion from the collab summit to that group @mcollina does that make sense to you?

[marco-ippolito]

@nodejs/releasers I think the general feeling that emerged from the previous discussions, is that changing the current release schedule requires a big effort and puts stress on people maintaining tools that need update to the new schedule. The consensus is that it's not worth changing the schedule unless there is a really important reason, which doesnt seem the case.

[mbabuskov]

The main problem is that major LTS releases are coming out too often. Any team that runs stable systems in production would love to have the same NodeJS version supported in parallel to their operating system support. There is absolutely no need for major new features after you ship a big application where you just want to patch bugs and add minor features within the existing feature set.

For such cases, having LTS release support for 4 years would be awesome. Startups that need to break things and move fast wouldn't run LTS anyway.

Please consider releasing LTS every 2 years with 4 year support and anything in between can be bleeding edge.

[mcollina]

@mbabuskov, sorry for the odd question: would you be willing to pay for it? If so, how much?

For the most part, Node.js follows the OpenSSL LTS schedule. To have "extended support" from OpenSSL, we'd need to pay a 50k/year license. A Node.js with longer LTS can't be OSS (use OpenSSL premium) or ABI stable (use a different version of OpenSSL, likely breaking all binary addons). Moreover, backporting security fixes is a significant amount of hidden hard work that most volunteers are not pursuing.

In essence, the longer LTS cycle is, the more work there is, however - who should pay for that work?