~/blog

Node 27 ends the odd/even release model in October

published Sep 17, 2026

#node#release#lts

TL;DR

Starting in October 2026, Node.js drops to one major release per year and every major becomes LTS. The odd/even rule that decided whether a release was safe for production is gone. Node 26 is the last release under the old model; Node 27 begins a six-month alpha in October 2026, ships as Current in April 2027, and enters LTS in October 2027.

The problem

For a decade the rule was: even numbers are LTS, odd numbers are not. That rule is load-bearing in a lot of places — CI matrices that test 20, 22, 24, engines ranges that assume the next production version is two numbers up, internal policies that say “even LTS only.”

All of it stops matching reality after October 2026. Skipping Node 27 because it is odd would mean skipping an LTS release.

What changes

From the official announcement: “Starting with 27.x, Node.js will move from two major releases per year to one.” And: “Every release becomes LTS. No more odd/even distinction — Node.js 27 will become LTS.”

The reasoning given is adoption. Odd-numbered releases saw minimal uptake, and the even/odd split confused newcomers, so half the release train was doing very little work.

Each major now moves through a fixed set of phases:

The alpha is the genuinely new piece. It uses semver prerelease versions such as 27.0.0-alpha.1, and unlike nightly builds these are signed, tagged and tested through CITGM. Semver-major changes are allowed during alpha, so the API can still move between alpha releases.

Version numbers now track the year

The new rule: “Version numbers align with the calendar year of their initial Current release: 27.0.0 in 2027, 28.0.0 in 2028.”

So the major version tells you the year it went Current. Node 27 is the 2027 release, even though its alpha starts in October 2026.

The two timelines

Node 26, the last release of the old model:

Node 27, the first of the new model:

Note what that means for planning: Node 26 is supported until April 2029, well past Node 27 entering LTS. There is no rush to move, and the migration windows between LTS versions are explicitly preserved.

What to do

Stop encoding the even/odd rule. If your CI matrix, docs or onboarding notes say “even-numbered releases only,” that line has an expiry date of October 2026. Replace it with “current LTS and the previous LTS.”

Check your engines ranges for odd-number exclusions. A range written to skip odd majors will now skip an LTS release:

{
  "engines": {
    "node": ">=22 <27"
  }
}

That upper bound was probably meant as “nothing newer than the current LTS.” After October 2026 it reads as “refuse the next LTS.” Prefer a lower bound plus an explicit test matrix over an upper bound you will forget to move.

Treat alpha as a real testing channel. A signed, tagged, CITGM-tested alpha is a better early-warning system than nightly builds, and six months is enough lead time to find breakage in native addons before Current. It is not a production channel — the API may change between alpha releases.

Do not rush off Node 26. It reaches end of life in April 2029, a year and a half after Node 27 enters LTS.

Caveats

• The 30-month LTS duration itself does not change, and neither do the quality gates, the testing process, or the V8 adoption cycle (still within roughly six months of a V8 release).
• Dropping to one major a year means breaking changes accumulate into a single annual step rather than two smaller ones. Whether that is easier depends on whether your upgrades are driven by calendar or by pain.
• Version-to-year alignment is a convention about the numbering, not a promise that a given year’s release lands on a given day.

References

• Node.js — Evolving the Node.js Release Schedule
• Node.js — Previous Releases and support matrix
• InfoQ — Node.js Moves to One Major Release Per Year, Starting with Node 27
• Socket — Node.js Moves to Annual Major Releases Starting with Node 27

────────────────────────────────────────