nodejs
Proposal - Shift Node.js to Annual Major Releases and Shorten LTS Duration
Background
Currently, Node.js operates on a biannual major release schedule. Even-numbered releases enter Long-Term Support (LTS), providing extended maintenance, while odd-numbered releases typically remain short-lived and experimental. This frequent cadence has increasingly strained project maintainers due to the complexity of managing concurrent release lines, backporting critical fixes, and ensuring compatibility across versions. Additionally, the rapid pace contributes to confusion within the Node.js community and broader ecosystem, complicating version selection and long-term planning.
Extensive discussions captured in #953 have raised these concerns, suggesting a shift to a simpler, more sustainable model could benefit both maintainers and users.
Proposed Change
The proposal is to transition Node.js from its current biannual major release cycle to a single annual major release. This annual release would follow a clearly defined lifecycle, offering greater predictability and stability. Concurrently, the proposal recommends shortening the Long-Term Support duration from the current total of 30 months to 24 months. This new duration would include approximately 12 months of active LTS support with regular updates and fixes, followed by an additional 12 months of maintenance LTS support focused primarily on critical security patches and essential bug fixes.
Therefore, each annual major release of Node.js will be promoted to LTS at some point (no more odd versus even release lines)
By implementing this schedule, Node.js can streamline resource allocation, reduce complexity in maintaining multiple active releases, and provide the community with a clearer and more predictable roadmap.
Benefits and Drawbacks
The key benefits of adopting an annual major release schedule with reduced LTS duration include a significantly reduced maintenance burden for core maintainers, leading to higher-quality releases with clearer long-term support commitments. It would enhance stability by providing users and ecosystem partners with a simplified, predictable framework for adopting and supporting Node.js versions.
On the other hand, the primary drawback of this approach is the potential reduction in the frequency of major new features and improvements. The pace of innovation in major Node.js features would be moderated, potentially delaying feature availability. Additionally, reducing the LTS period could initially face resistance from parts of the community accustomed to longer support windows.
Implementation Strategy
Implementing this proposal would begin with obtaining consensus from the Node.js Technical Steering Committee (TSC) and the Release Working Group. Upon agreement, the Node.js project would immediately update its official documentation, clearly outlining the new annual release schedule and the revised LTS policy.
The introduction of the new release schedule would be accompanied by detailed, proactive communication efforts to clearly set expectations across the entire Node.js ecosystem. Regular feedback collection and policy refinement would follow the implementation, ensuring ongoing alignment with community needs and expectations.
Next Steps
Moving forward, detailed discussions within the Release Working Group will be crucial to refining this proposal. Comprehensive transition documentation, clear timelines, and active ecosystem communication strategies will be prepared and disseminated.
Community feedback is encouraged and welcomed to ensure this proposal best meets the needs of the entire Node.js ecosystem.
Marking it tsc-agenda as well.
Personally, I’m generically +1.
I propose two changes:
- reduce the deprecation time window, so we could land runtime deprecations in minors in the active line.
- increase the window for security releases for our Tier 1 platforms for one additional year (literally no other releases, just security things): we could mark it as “best effort” depending on community resources.
I'm definitely a big +1 on revisiting the release and LTS plan. When I first proposed the current plan a decade ago it was based entirely on corporate adoption cycles that were relevant at that time and we really haven't revisited the plan since. It's always good to periodically revisit to see if the needs of ecosystem and the project have changed.
That said, i want to make sure that we're not going into the discussion in a vacuum. It should not only be based on what we think is best or easiest for us to maintain but also on what the ecosystem actually needs.
For instance, the current approach we take where there is a 6 month overlap between major releases and the previous LTS release going out of active was specifically designed to give companies a time where they can move from one LTS supported major to another LTS supported major incrementally over a period of months where they would always be ensured whatever version they are actively using is supported. I think that whatever cycle we adopt needs to preserve this. It can take months for a large organization to migrate and they should never be put in a position where the version they are moving away from falls out of active LTS support in mid-transition.
I'm a BIG +1 on moving to a single major release per year, but given the above I think a fixed 12 month support cycle does not give enough of an overlap. I would suggest that 1 major with an 18 month support lifespan is likely the safest.
Another significant change that I think we should make with releases is moving away from backporting feature changes. I think the only things we should be backporting to older versions are bug fixes... and in particular vulnerability fixes. New stuff should be reserved for new releases, period, which would go a long way towards incentivizing the ecosystem to move to newer versions and would greatly reduce the overhead of managing releases in general.
I would also agree that we can likely reduce our strict handling of runtime deprecations. EOL's should always be semver-major but I think we've reached a point where runtime deprecations can likely become semver-minor. It's been years since I've seen the addition of a runtime deprecation actually breaking something.
+1 to one major per year
I also agree to
reduce the deprecation time window, so we could land runtime deprecations in minors in the active line.
Backporting to old release lines is HARD so having a shorter lifespan makes releasers life easier.
moving away from backporting feature changes
do note that this will dramatically slow the ability of libraries to rely on new node features - if we hadn't backported "require(esm)", for example, it'd still not be feasible for most people to start shipping ESM-only.
moving away from backporting feature changes
do note that this will dramatically slow the ability of libraries to rely on new node features - if we hadn't backported "require(esm)", for example, it'd still not be feasible for most people to start shipping ESM-only.
require(ESM) backport was an exception since v20 was already in maintaince mode. We can still make expections
True :-) but any feature that's not backported will take years longer before libraries can rely on it.
In reality this results in only 12 months of LTS, which I would hesitate to call LTS. Say I upgrade to Node 24 now. 2 years from now, I get spammed by compliance about our Node being EOL. I will not risk upgrading to a day old major release (and no real company will either), but instead upgrade to 25. But then next year 25 is EOL, and only then I can upgrade to 26. And so on.
Expecting yearly upgrades from users, where a couple of months ago there was big drama about selling EOL support on the website to Node 16/18 users, is an unexpected pivot, not going to lie.
In reality this results in only 12 months of LTS, which I would hesitate to call LTS. Say I upgrade to Node 24 now. 2 years from now, I get spammed by compliance about our Node being EOL. I will not risk upgrading to a day old major release (and no real company will either), but instead upgrade to 25. But then next year 25 is EOL, and only then I can upgrade to 26. And so on.
Expecting yearly upgrades from users, where a couple of months ago there was big drama about selling EOL support on the website to Node 16/18 users, is an unexpected pivot, not going to lie.
Concurrently, the proposal recommends shortening the Long-Term Support duration from the current total of 30 months to 24 months This new duration would include approximately 12 months of active LTS support with regular updates and fixes, followed by an additional 12 months of maintenance LTS support focused primarily on critical security patches and essential bug fixes.
it's 24 months of LTS, not sure where you read 12 months... Not going to comment on your speculations
This proposal shortens the maintainance mode from 1 year and half to 1 year (-6 months)
True :-) but any feature that's not backported will take years longer before libraries can rely on it.
Not disagreeing ;-) ... just saying that I would love to have more of a forcing function to encourage users to upgrade sooner
Major Node.js versions enter Current release status for six months, which gives library authors time to add support for them. After six months, odd-numbered releases (9, 11, etc.) become unsupported, and even-numbered releases (10, 12, etc.) move to Active LTS status and are ready for general use. LTS release status is "long-term support", which typically guarantees that critical bugs will be fixed for a total of 30 months. Production applications should only use Active LTS or Maintenance LTS releases.
If I steelman the proposal, it's still only 18 months of LTS. Today, right now, you guys don't recommend the even numbered release until after 6 months. My question is what changes your confidence in calling a brand new day-old release LTS?
I don't know what is hard to understand about my example in my previous comment.
- Why should anyone risk upgrading to Node 24 on May 4 2025?
- In April/May 2026 should Node 24 users upgrade to Node 25 (under new proposal) or keep using Node 24 for another year?
- In April/May 2027 should Node 24 users upgrade to a brand new Node 26 with zero users, or a year old mature Node 25?
- If they upgrade to Node 25, how many months of support they get from that point onwards?
(hint: 12 months)
empirically, "new features you need to upgrade to get" hasn't actually forced all that many people to upgrade, sadly (looking at the download stats from nodejs.org)
Major Node.js versions enter Current release status for six months, which gives library authors time to add support for them. After six months, odd-numbered releases (9, 11, etc.) become unsupported, and even-numbered releases (10, 12, etc.) move to Active LTS status and are ready for general use. LTS release status is "long-term support", which typically guarantees that critical bugs will be fixed for a total of 30 months. Production applications should only use Active LTS or Maintenance LTS releases.
If I steelman the proposal, it's still only 18 months of LTS. Today, right now, you guys don't recommend the even numbered release until after 6 months. My question is what changes your confidence in calling a brand new day-old release LTS?
I don't know what is hard to understand about my example in my previous comment.
- Why should anyone risk upgrading to Node 24 on May 4 2024?
- In April/May 2025 should Node 24 users upgrade to Node 25 (under new proposal) or keep using Node 24 for another year?
- In April/May 2026 should Node 24 users upgrade to a brand new Node 26 with zero users, or a year old mature Node 25?
- If they upgrade to Node 25, how many months of support they get from that point onwards?
The 6 months of current are not going to change. After a release is cut it goes 6 months into a current state, then it becomes lts for 30 months, the proposal cuts it to 24. The total lifespan now is 36 months, 6 of current + 30 of LTS for a total of 3 years. Also the proposal will not affect pre-existing releases
empirically, "new features you need to upgrade to get" hasn't actually forced all that many people to upgrade, sadly (looking at the download stats from nodejs.org)
and that's fine for me. If users don't need the new features then they don't need to upgrade unless they get to the point where they can't get bug fixes for the stuff they are using.
empirically, "new features you need to upgrade to get" hasn't actually forced all that many people to upgrade, sadly (looking at the download stats from nodejs.org)
and that's fine for me. If users don't need the new features then they don't need to upgrade unless they get to the point where they can't get bug fixes for the stuff they are using.
New releases are not made only for features. They are supposed to fix things, like vulnerabilities and stuff.
... New releases are not made only for features. They are supposed to fix things, like vulnerabilities and stuff.
Yes, please see my previous comments here ;-) ... I'm talking only about limiting backports of new features, not fixes.
Huge +1. This will simply the releases a lot and also seems like we are in a good momentum for this change (even if we "reduce" the frequency of major new features and improvements)
My main suggestion would be to keep the LTS at 30 months, but no objection with dropping the odd currents.
If I'm understanding correctly, this would mean changing from this:
to something like this?
(Note, there's a nice side effect here were Node.js 26 is releases in 2026, Node.js 27 in 2027, etc.)
Thanks for visualising.
It looks like in the current model, there is always an ongoing Active LTS release at any given point in the maintenance LTS window. Allowing users to effectively use an LTS version for 2 years and then "skip" an LTS version and upgrade to the 2 numbers higher (ie. from 20 to 24) every two years.
With the new model this stops being possible. Meaning users have to upgrade from Maintenance LTS to Active LTS every year to not risk being stuck on EOL product. The green 6 month grace period is a no-go for production apps according to your own policy.
No? To me this is an obvious regression in mandatory major version upgrade frequency.
Because this amounts to 12 months of effective LTS.
to something like this?
What would "Active LTS" mean if there are no "Current" at the same time? Our current policy is that commits are included on LTS releases only if they've been released for two weeks, so are we expecting those to receive commits directly from main (i.e. like Current, but with less frequent releases)?
Regulations like SOX (Sarbanes-Oxley Act) and Basel III significantly increase the time required for system upgrades due to their complexity and the need for rigorous compliance procedures. It is normal for a financial system to spend 6-8 months worth of mandatory paperwork even before attempting to flip the switch.
For example, if Node 26 is released on January 1st, it takes several months to test it out, then undertake all the steps to meet the compliance requirements, which are likely to take the major part of that year, thus the actual release can only take place by the end of the year. Which effectively means that shortly after releasing it, you'll immediately have to start all over again, because the release will only last 1 year, and it's very easy to miss the mark.
The new timeline is simply too short to be viable. Even the current one stretches it.
I'm in general very supportive of reducing the maintenance burden for all involved parties. That being said it is a tug of war situation with users and companies pulling the other end of the rope opposite of maintainers and releasers, I don't think there's much leeway that allows to shorten the overall LTS duration (Active + Maintenance) while retaining a 1 year major cadence.
Because whatever the total LTS duration is, its % (modulus) the major-release cadence must not be 0 so that users are able to skip a major and still be covered by LTS whilst waiting on the next one to be promoted to LTS and having enough time to actually do the upgrade and run it through its paces, this is often times a non-trivial process.
Would limiting Active LTS duration while prologing the Maintenance LTS by the same amount (or the opposite), thus keeping the same total duration, help the releasers situation?
I'm very supportive of reducing the frequency of releases and cutting the odd non-LTS release lines. I do have a few specific concerns, but I don't think they're necessarily blocking to this.
Currently we're seeing a feature renaissance in JavaScript runtimes. All of the core contributors have done an amazing job picking up and running with new features that there's been clear user demand for, largely (imo!) signaled by other runtimes shipping them to much fanfare. There's a few facets to this:
- I am worried about dramatically slowing down the frequency with which we get to ship new features like this and missing critical windows of adoption in the space of JavaScript runtimes.
- Similarly, I'm also worried about something I've seen under the current system a number of times: a semver major feature that is widely agreed upon but not quite ready coming in at the eleventh hour and just missing the window... then having to wait another year.
- Often the odd releases, to me at least, feel like a good "we get to ship a bunch of features and test them out to get them ready for LTS" period, and we'll be losing that and cramming in ~double the new features which can increase the surface area for instability or critical issues to be missed. It's a trade off, and I do think it's a reasonable one to make! It's also worth considering how we feel this will play out given a ~decade of historical data we could make rough conclusions from.
Additionally, I'm not totally sure how to feel about adoption. Personally, at both companies I've worked for that effectively sell cloud environments with Node.js built-in and have run millions of apps on those environments, the only useful mechanism to get them to care about upgrading is the minimum release line going EOL. Tightening that window will mean that overall the cloud environment ecosystem will be... stronger and move more closely with the runtime, and I'm a huge fan of that motivation coming from the runtime itself.
I will say, I'd be curious if the Foundation has any data on regulatory environments that can help us be more aware of regulated timelines like the one @WillAvudim mentions.
I can see less frequently apps/packages jumping from even to even or odd to odd once at the end of LTS to avoid updating every year. Some repos just aren't that active, especially the nice ones that have few dependencies. As for backporting, just leave it as experimental on the older version but consider keeping it in sync. IIRC, you have to enable the feature or it will generate console warnings while using the experimental. If you don't like the warnings, upgrade to the next stable/LTS that doesn't generate those console warnings.
Just for the record and for proper documentation. Biannually as in twice a year or once every two years?
Regulations like SOX (Sarbanes-Oxley Act) and Basel III significantly increase the time required for system upgrades due to their complexity and the need for rigorous compliance procedures. It is normal for a financial system to spend 6-8 months worth of mandatory paperwork even before attempting to flip the switch. The new timeline is simply too short to be viable. Even the current one stretches it.
For regulatory compliance, the correct approach may be to partner with a provider that can promise longer support lifecycles. This is probably already true for other requirements, like FIPS. 😉
I don't consider reduced frequency of majors to be a significant problem. In most cases we have found ways to turn majors into minors through flagging or delaying a behaviour switch in new code until the next major, just having some temporary code to keep existing behaviours until they can be removed at the next major. In fact, I think it's a feature that majors happen less often as it forces us to be more deliberate about our majors and plan accordingly.
We've had a bunch of cases where major changes landed without much thought and broke things, but because they happened in an odd release we just shrugged and thought "we'll just fix it in the next major, no one uses odd releases anyway" rather than reverting immediately and calling that a bug. I think we could do with more accountability with what gets shipped and so a lot more caution about shipping new code without some time behind a flag.
That's all to say that I think we should be focusing on less concurrent releases splitting our attention, and instead focus on a limited set of active releases with all new development going purely to the latest release line and only bug/security fixes getting backported to prior majors.
As someone who has not struggled with big migrations and has worked mostly in the startup space: Do whatever ensures Node's maintainability (and your sanity) the longest.
A major per year sounds easier than the current even-odd system in all aspects, and let's be honest, too many people and companies still use Node 12-18 as of today (they have hundreds of millions of downloads per month still!¹).
If someone is not willing to upgrade and is fine with using EOL versions in the first place, reducing the time they reach that point by 6 months won't make a difference to them, but will do to the Node Core Team. I ultimately care far more about the latter.
As for companies that do have to migrate, if releases are smaller, so should migration efforts be. I wouldn't be surprised if many of those changes cannot be automated or at least, the upgrade process takes far less time (for anyone in corporate, that's a free plus for your summary of achievements! 😉)
¹From Matteo Collina's State of Node.js 2025
@alexaka1 If I understand that correctly, that would be solved by keeping the maintenance LTS window open for 6 more months, like it is today. Right?
Similarly, I'm also worried about something I've seen under the current system a number of times: a semver major feature that is widely agreed upon but not quite ready coming in at the eleventh hour and just missing the window... then having to wait another year.
@bnb this is already the case. If they miss the semver-major cut in March, they won't be in a LTS release.
If I understand that correctly, that would be solved by keeping the maintenance LTS window open for 6 more months, like it is today. Right?
@mcollina I think so.
Without looking at active lts vs maintenance lts, and just taking the window, 30 months, then the only thing that changed is there is no more fall release for Node. If I'm correct. So if that is the case then the first picture still applies as is, meaning that even though the total support window, from release till EOL is 36 months, from an LTS standpoint, the first 6 are a no-go, and the remaining 30 will only be effectively utilized for give or take 24 months (because ideally you would upgrade before it becomes EOL, so there is always some lost support window). You'd have to draw the proper timeline, that helped me a lot to visualize it.