Node Moves to One Release a Year — and Fixes the Smaller Problem

On 10 March 2026 the Node.js project announced that from version 27 there will be one major release a year, and every one of them becomes LTS. The odd-numbered release — the one that shipped, got used by almost nobody, and died eight months later — is gone. That is a real simplification of version selection, and the project's own download telemetry says selection was never the expensive problem.

Nothing has shipped yet. As of 31 August 2026 the supported lines are v22 in maintenance, v24 in Active LTS, v26 as Current. The v27 Alpha channel opens on 28 October 2026; the stable release follows in April 2027. So this is a change to plan around, not one to react to.

The odd-numbered release is what disappears

The phase structure gets flatter, not shorter.

Odd majors never entered that table. They ran ~6 months as Current plus a short security-and-docs tail, roughly 8 months end to end, and by design could never become LTS. Node v25 shipped 15 October 2025 and reached EOL on 1 June 2026 — the last of them.

Version numbers now track the calendar year of the stable release: v27 in 2027, v28 in 2028. Convenient, and the single most-quoted part of the announcement, which tells you something about how much else is actually moving.

The second figure is the one that matters and the one nobody leads with. Dropping to one major a year does not reduce the number of production lines the project carries, because it was never the odd releases that were being carried. Marco Ippolito, in an interview with HeroDevs (a vendor that sells post-EOL support, so read the framing accordingly), puts the real cost elsewhere: Node 22 and Node 26 "have diverged enough that backporting a single commit between them has become genuinely difficult." Annual cadence widens that gap rather than closing it.

Why the 30-month LTS window survived

The proposal that started this asked for something more aggressive. Issue #1113, opened by Rafael Gonzaga on 14 July 2025, paired the annual cadence with a shortened LTS window: 24 months, split 12 active and 12 maintenance.

It did not survive the thread. On 23 July 2025 richardlau relayed IBM and Red Hat client feedback that the 30-month window had to stay, because those clients "don't want to/can't move up to newer releases on a yearly basis." Another commenter, WillAvudim, made the mechanism concrete: "It is normal for a financial system to spend 6-8 months worth of mandatory paperwork even before attempting to flip the switch." The annual cadence shipped. The shortening did not.

James Snell, who authored the original 2015 cadence design, conceded the point from the other side in the same thread: the old plan "was based entirely on corporate adoption cycles that were relevant at that time and we really haven't revisited the plan since." Stale, not wrong.

Thirty months puts Node mid-pack among runtimes that made the same move:

The Java row rests on two secondary sources — Oracle's own cadence page returns 403 to automated fetches, so treat that line as cross-referenced rather than primary.

1. 9 November 2023

   Collina opens nodejs/Release#953

   the empirical seed

   CDN download-log analysis showing "very few people are downloading the releases that are not going to become LTS", with bug reports rarely coming from non-LTS users.

2. 14 July 2025

   Gonzaga opens nodejs/Release#1113

   annual cadence + 24-month LTS

   Cites two problems: backporting across concurrent lines strains maintainers, and the odd/even split complicates version selection.

3. 23 July 2025

   IBM and Red Hat push back

   30 months retained

   richardlau relays enterprise client feedback against shortening the LTS window. The 24-month proposal is dropped.

4. 10 March 2026

   nodejs.org publishes the new schedule

   v27 onward

   One major a year, every major LTS, calendar-aligned version numbers, a new Alpha channel.

5. 28 October 2026

   v27 Alpha opens; v26 enters LTS

   ~2 months out

   The first date on this list that appears on anyone's maintenance calendar.

6. April 2027

   v27.0.0 stable

   day-level date still shifting

   First major under the new model. LTS entry follows around October 2027; EOL 30 April 2030.

The Alpha channel is a compromise, not a replacement

Removing the odd release removes the only pre-LTS build that real users ran. That objection came from inside: targos, on the Node core and release teams, argued in #1113 on 16 July 2025 that a six-month gap with no dogfooded Current release leaves new code effectively untested before it reaches production users. The Alpha channel exists because of that argument.

What it is: signed, tagged builds (27.0.0-alpha.1 and up) running from October to March, put through CITGM against major open-source packages. What it is not, per the project itself: suitable for production. panva, in the same thread, was sceptical it would attract testing comparable to a genuine Current release, and no evidence either way exists yet — the channel opens in two months.

The unglamorous version of the problem is still open in docker-node#2524, filed 27 May 2026: whether Docker images get published for the alpha tags at all. If you are being asked to test against Alpha, that is the question that decides how much friction it costs you.

Which teams have to touch a CI matrix

If you already follow Node's own advice and test against LTS only, the answer is none. Your matrix is already a list of LTS majors, and it stays one.

The teams that change something are the thorough ones. A matrix built to cover everything supported looked like [20, 22, 24, 25] — four entries, one of them an odd release with months to live. The equivalent under the new model is [22, 24, 26]: three entries, all durable. Roughly a quarter fewer jobs, and the entry you stop maintaining is the one that was churning twice a year.

The mechanics need no rework. actions/setup-node has supported LTS aliases such as lts/* and lts/jod since well before this, and its recommended pattern — list the supported LTS majors explicitly — survives unchanged. Docker tags are the same story: node:lts and node:current were always relative pointers into the schedule. The concrete prep work in that repo, issue #2435 from 30 March 2026, moved the Debian base from bookworm to trixie and dropped oldstable builds to cut the build-combination count. Matrix hygiene, not a tagging redesign.

What the download telemetry says the real problem is

Here is the number the announcement does not contain.

Two caveats first. The Node 26 bar is derived from HeroDevs' statement that Node 20 out-downloads the current line "better than two to one", not reported as a figure; the Node 18 bar comes from a NodeSource post over the same telemetry that could not be re-fetched independently. Only the Node 20 number is directly sourced, and it carries the point on its own.

An end-of-life release out-pulling the current line two to one, three months after support stopped, is not a version-selection failure. Nobody downloading Node 20 in July 2026 was confused about whether it was LTS. They knew, and they stayed. The OpenJS Foundation has repeated since November 2024 that roughly two-thirds of Node users run outdated or unsupported versions, a vendor claim with no disclosed methodology or sample size either time it was published, so treat the ratio as directional and the direction as consistent with the chart.

The redesign targets the confusion problem, which is real: issue #953 documented it with CDN logs in 2023, and the fix is clean. It does not touch the inertia problem, which is bigger. No source in this area publishes an "average time to upgrade after a new LTS ships" figure — a genuine gap, not an oversight in the searching.

Whether cadence alone can move adoption has a partial answer elsewhere. Java has run a six-month cadence since JDK 9 in 2017, and the ten-year retrospectives on it converge on the same conclusion: predictable releases did not measurably accelerate enterprise uptake. Meanwhile .NET, which reached annual cadence earlier, is currently fielding complaints that its 3-year LTS window is too short for enterprise cycles — the exact objection that kept Node at 30 months.

Is there anything to do before October 2026?

For most readers, no. The reason is the point of the article rather than a shrug.

• You test against LTS only. Nothing changes now. The next two dates on your calendar are v26 entering LTS on 28 October 2026 and v22 reaching EOL on 30 April 2027, both scheduled under the old rules and unaffected by any of this.
• You maintain a published library. The one real transfer of work. From 28 October 2026 the 27.0.0-alpha.x tags are the only pre-production surface that exists, and the project is asking maintainers to wire them into CI. Watch docker-node#2524 first if your CI is image-based.
• You have an odd major pinned anywhere. Node 25 has been EOL since 1 June 2026. That is an existing problem the new schedule neither caused nor fixes.
• Your upgrade policy triggers on "enters Maintenance LTS". Re-key it to dates before v27, because that phase name stops existing.

The honest summary of the change is the project's own: if you already upgrade only to LTS, little changes beyond version numbering. That framing is accurate and it is also the tell. A schedule redesign whose main benefit accrues to people who were already doing the right thing is not going to move the population in the chart above.