# Node moves to one release a year, and fixes the smaller problem

> From v27 every Node major becomes LTS and odd releases disappear. What that changes in a CI matrix, why the 30-month window survived, and what it misses.

- Source: https://ivankarpinskyi.dev/blog/node-annual-release-cycle
- Published: 2026-09-01
- Type: Changes
- Tags: nodejs, release-cycle, lts, ci, upgrades
- Reading time: 9 min

On 10 March 2026 the Node.js project [announced](https://nodejs.org/en/blog/announcements/evolving-the-nodejs-release-schedule) 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.

| Phase | Old scheme (even majors) | New scheme (v27+) |
| - | - | - |
| Alpha | — | 6 months (Oct → Mar) |
| Current | 6 months | 6 months (Apr → Oct) |
| Active LTS | 12 months | — |
| Maintenance LTS | 18 months | — |
| LTS (single flat phase) | — | 30 months |
| Total, first Current release to EOL | 36 months | 36 months |

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](https://nodejs.org/en/about/previous-releases) 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.

- **Node majors released per year**: 2 → 1. Annual April release from v27; the October slot becomes the Alpha channel.
- **LTS lines supported concurrently**: 3 → 3. Unchanged: \~12-month LTS spacing against a 36-month lifecycle, under both schemes.

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](https://www.herodevs.com/blog-posts/node-js-moving-to-one-release-a-year) (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.

> **Warning · Upgrade policies keyed to phase names will silently stop firing**
>
> Under the new scheme LTS is one flat 30-month phase with no named Active/Maintenance split. Any internal rule shaped like "we move off a release when it enters Maintenance" has no trigger to fire on from v27 onward. Re-key those policies to dates.

## Why the 30-month LTS window survived

The proposal that started this asked for something more aggressive. [Issue #1113](https://github.com/nodejs/Release/issues/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.

> **The point**
>
> The reversal is more informative than the announcement. Node's production base defended support-window _length_, not release frequency — which is the same preference the download data below expresses, just stated out loud.

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:

| Runtime | Cadence | Support window |
| - | - | - |
| [Node.js](https://github.com/nodejs/Release) (v27+) | annual (April) | 30 months LTS, 36 total from Current |
| [Python](https://peps.python.org/pep-0602/) | annual (October) | 60 months (24 bugfix + 36 security) |
| [.NET](https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core) | annual (November) | LTS 36 months / STS 24 months, alternating |
| [Ruby](https://www.ruby-lang.org/en/downloads/branches/) | annual (25 December) | \~36 months, no LTS tier |
| Java / OpenJDK | every 6 months | LTS every 24 months; non-LTS lines 6 months |

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.

- **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.
- **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.
- **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.
- **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.
- **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.
- **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](https://github.com/nodejs/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](https://github.com/nodejs/docker-node/issues/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`](https://github.com/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](https://github.com/nodejs/docker-node/issues/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.

**Node downloads, July 2026**

| | Value, M | Note |
| - | -: | - |
| **Node 20 (EOL 30 Apr 2026)** | 103.8 | 3 months post-EOL |
| Node 26 (Current since May 2026) | 52 | derived, not reported directly |
| Node 18 (EOL Apr 2025) | 32.7 | figure not re-confirmed on fetch |

_nodejs.org CDN download telemetry, aggregated by nodedownloads.nodeland.dev and reported by HeroDevs on 3 August 2026. The source states raw download counts and no further method._

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](https://github.com/nodejs/Release/issues/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](https://www.theregister.com/devops/2026/06/29) 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](https://github.com/nodejs/docker-node/issues/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.

> **Note · Currency**
>
> Written 31 August 2026. Node v27 has not shipped: Alpha opens 28 October 2026, stable lands April 2027 (the day-level date has shifted between published schedule revisions), LTS entry follows around October 2027. Current lines at time of writing are v22 (maintenance), v24 (Active LTS) and v26 (Current). Check [nodejs/Release](https://github.com/nodejs/Release) for the live schedule before acting on any date here.

## Sources

- [announced](https://nodejs.org/en/blog/announcements/evolving-the-nodejs-release-schedule), nodejs.org
- [Node v25](https://nodejs.org/en/about/previous-releases), nodejs.org
- [an interview with HeroDevs](https://www.herodevs.com/blog-posts/node-js-moving-to-one-release-a-year), herodevs.com
- [Issue #1113](https://github.com/nodejs/Release/issues/1113), github.com
- [Node.js](https://github.com/nodejs/Release), github.com
- [Python](https://peps.python.org/pep-0602/), peps.python.org
- [.NET](https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core), dotnet.microsoft.com
- [Ruby](https://www.ruby-lang.org/en/downloads/branches/), ruby-lang.org
- [CITGM](https://github.com/nodejs/citgm), github.com
- [docker-node#2524](https://github.com/nodejs/docker-node/issues/2524), github.com
- [actions/setup-node](https://github.com/actions/setup-node), github.com
- [issue #2435](https://github.com/nodejs/docker-node/issues/2435), github.com
- [issue #953](https://github.com/nodejs/Release/issues/953), github.com
- [complaints](https://www.theregister.com/devops/2026/06/29), theregister.com