Proposal - Shift Node.js to Annual Major Releases and Shorten LTS Duration

[RafaelGSS]

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.

[mcollina]

Marking it tsc-agenda as well.

Personally, I’m generically +1.

I propose two changes:

1. reduce the deprecation time window, so we could land runtime deprecations in minors in the active line.
2. 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.

[jasnell]

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.

[marco-ippolito]

+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.

[ljharb]

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.

[marco-ippolito]

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

[ljharb]

True :-) but any feature that's not backported will take years longer before libraries can rely on it.

[alexaka1]

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.

[marco-ippolito]

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)

[jasnell]

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

[alexaka1]

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)

[ljharb]

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)

[marco-ippolito]

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