Node Goes Annual. October Is When It Bites.
Quick answer: Node.js is dropping the odd/even release model. From Node 27 onward there is one major per year, released in April, and every major becomes LTS. October 2026 is the first October in a decade with no new major version: Node 26 becomes Active LTS on 28 October 2026, Node 24 drops to maintenance on 20 October 2026, and Node 27 starts a six-month alpha instead of shipping. If your CI matrix, Dockerfile or engines field assumes a fresh odd release every autumn, it will quietly stop tracking reality.
For ten years the Node release rhythm was a thing you could set a calendar reminder by. April brought an even major. October promoted it to LTS and shipped an odd major nobody ran in production. You skipped the odd ones, upgraded the even ones every two years, and the version matrix wrote itself.
That ends now. The Node.js project announced on 10 March 2026 that Node 26 is the last release under the old model. Node 27 is the first under the new one, and it does not arrive in October 2026. It arrives in April 2027, after six months in an alpha channel that did not previously exist.
What actually changed
Four things, and only the first is the headline:
One major per year, not two. April only. October becomes a promotion date, not a release date.
Every major becomes LTS. The odd/even distinction is gone. There is no longer a class of release you are expected to skip.
A six-month alpha phase. October to March, semver-major changes allowed, versioned as prereleases such as 27.0.0-alpha.1. This is where the odd release used to live, except now it is honestly labelled.
Version numbers track the calendar year. Node 27 in 2027, Node 28 in 2028. After a decade of mentally converting "Node 22" into "that's the 2024 one", the number finally tells you.
The support window is unchanged in total length: six months Current, then 30 months LTS, so 36 months from first release to end of life. What changes is that you now get one of these per year instead of one every two years that matters and one that does not.
The October 2026 calendar, precisely
These are the dates from the nodejs/release schedule. Two of them land inside the next five weeks.
| Version | Status today | Next transition | End of life |
|---|---|---|---|
| Node 20 | End of life | None | 30 Apr 2026 (passed) |
| Node 22 | Maintenance LTS | None | 30 Apr 2027 |
| Node 24 | Active LTS | Maintenance, 20 Oct 2026 | 30 Apr 2028 |
| Node 26 | Current | Active LTS, 28 Oct 2026 | 30 Apr 2029 |
Read the third row again. On 20 October 2026 the version most production fleets are standardised on stops receiving anything but security and critical fixes. Eight days later the version most of them have not tested becomes the recommended target. That eight-day gap is the whole upgrade story for the next twelve months, and there is no odd release arriving to distract from it.
Why the odd releases died
Because almost nobody ran them. Node maintainers have said plainly that odd-numbered releases saw minimal adoption while still costing the project real backporting work across concurrent release lines. Every feature that landed in an odd release had to be maintained, documented and eventually forward-ported for an audience that mostly waited six months for the even one.
That is not a Node-specific insight. Python moved to annual releases with PEP 602 in 2019. .NET has shipped one major a year for years. The industry converged on calendar-predictable majors because that is what upgrade planning actually wants: a date you can budget against, not a cadence you have to decode.
The honest reading is that the odd/even model was already dead in practice and the project just stopped paying to keep the corpse warm. If you have been skipping odd releases on purpose, nothing about your behaviour changes. Only the label does.
The alpha channel is not a beta, and that matters
Semver-major changes are explicitly allowed during the alpha window. That is the whole point: breaking changes get six months of real-world exposure before they are frozen into a release everyone is expected to adopt. Under the old model a breaking change landed in an odd release that few people ran, then arrived in the even release six months later having been tested by almost nobody.
The practical consequence: if you maintain a library, a native addon, or anything that touches Node internals, the alpha window from October 2026 to March 2027 is where you find out what breaks. Waiting for April 2027 means finding out at the same time as your users. That is a worse deal than it used to be, because now there is no odd release acting as an early-warning system on your behalf.
Library maintainers who already test against nightlies lose nothing. Everyone who relied on "wait for the odd release to shake it out" needs a new plan, and the plan is the alpha channel.
What to change before 20 October
Audit what your CI matrix actually pins
A matrix of [20, 22, 24] is testing one end-of-life version, one maintenance version and one that is about to leave active support. Setups that use lts/* will silently move from 24 to 26 on 28 October, which is either exactly what you want or a surprise deploy, depending on whether you have tested 26. Decide which before the date, not after. The same discipline applies to runner images generally, not just Node — pinning is only useful if someone re-reads the pin occasionally.
Fix your engines field
Ranges written as >=18 or ^20 || ^22 now encode assumptions about a version numbering scheme that no longer exists. With annual majors, an engines range that enumerates even numbers will start excluding perfectly supported releases from 2027.
Test Node 26 now, not in November
Node 26 is not a quiet release. It removed the --experimental-transform-types escape hatch, which changes what TypeScript its native type stripping will and will not run. We covered exactly what breaks there, and it is the single most likely thing to bite a codebase moving from 24 to 26. Combine that with a bundler migration such as Vite 8's move to Rolldown in the same sprint and you will not know which change caused the failure.
Write the 2027 date down somewhere
Node 27 ships April 2027 and becomes LTS in October 2027, the same month Node 26 drops to maintenance. From here on, every October is a handover month and every April is a new major. That is a two-line entry in whatever runbook holds your upgrade cadence, and it replaces the mental model most teams have carried since 2015.
What this does not change
Support length per release is the same 36 months. Security backport policy is the same. The April release date for majors is the same one even releases already used. And nothing about this changes the rest of your supply chain — npm's move to trusted publishing and the registry's token changes are a separate migration on a separate clock.
What it does change is the shape of the decision. You used to choose between two live LTS lines. From 2027 you choose between three, all of them LTS, all of them one calendar year apart. That is more choice, not less — and more versions to have an opinion about. If you are auditing runtimes and build tooling generally, the developer tools directory and the cloud and DevOps category are where the CI and runtime products live, and open-source listings cover the self-hosted end.
FAQ
Is there a Node 27 release in October 2026?
No. October 2026 is when Node 27 enters its six-month alpha phase. The stable 27.0.0 release is scheduled for April 2027, and it enters LTS in October 2027.
When exactly does Node 26 become LTS?
28 October 2026, per the nodejs/release schedule. Node 26 was first released on 5 May 2026, moves to maintenance on 20 October 2027 and reaches end of life on 30 April 2029.
Does the total support window get shorter?
No. Each major still gets six months as Current plus 30 months of LTS, for 36 months total from first release to end of life. That is unchanged from the even releases under the old model.
What happens to Node 24 on 20 October 2026?
It leaves Active LTS and enters maintenance, meaning critical bug fixes and security updates only. It stays supported until 30 April 2028, so this is not an emergency — but new features and non-critical fixes stop landing there.
Should library maintainers test against the alpha channel?
Yes, if you ship anything that touches Node internals or native addons. Semver-major changes are permitted during the alpha window, and there is no longer an odd release acting as an unofficial early-warning system between announcement and adoption.
Do version numbers really match the calendar year now?
Yes. Node 27 releases in 2027, Node 28 in 2028, and so on. Node 26 is a coincidence rather than the start of the pattern — it shipped in 2026 under the old model.
The version number finally means something. Put 20 and 28 October in the calendar before they mean something you did not plan for.