Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
mcollina opened this issue Nov 9, 2023 · 20 comments

Comments

@mcollina
Copy link
Member

mcollina commented Nov 9, 2023

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/

Screenshot 2023-11-09 at 11 29 59

(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
Copy link
Contributor

aduh95 commented Nov 9, 2023

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
Copy link

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.
immagine
The same pattern is visible here.
immagine

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
Copy link
Member

BethGriggs commented Nov 9, 2023

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
Copy link
Member

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
Copy link
Member Author

mcollina commented Nov 9, 2023

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
Copy link
Member

Qard commented Nov 10, 2023

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

targos commented Nov 13, 2023

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
Copy link

gurgunday commented Nov 13, 2023

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
Copy link
Member

Qard commented Nov 13, 2023

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
Copy link
Member

targos commented Nov 13, 2023

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
Copy link
Member

ljharb commented Nov 13, 2023

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
Copy link
Member

Qard commented Nov 13, 2023

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
Copy link
Member

ljharb commented Nov 13, 2023

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

marco-ippolito commented Mar 7, 2024

@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
Copy link

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
Copy link
Member Author

mcollina commented Jun 24, 2024

@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?

@targos targos changed the title proposal for new release schedule / users are not interested in releases that will not become LTS Proposal for new release schedule / users are not interested in releases that will not become LTS Jun 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests