Node.js Is Going to One Release Per Year — and Honestly, It's About Time
3. 6. 2026
Node.js is dropping to one major release per year starting with v27. No more odd/even chaos, no more short-lived releases nobody runs in production. Here's what actually changes and what it means for your upgrade cadence.
Node.js 26, which shipped in April 2026, is the last release under the old model. Starting with Node 27 in October 2026 (alpha phase), the project moves to a single major release per year. One. Every version becomes LTS. The odd/even game is over.
I genuinely don't understand why it took a decade to get here. The old system — two majors a year, only even numbers getting LTS — was designed in 2015 during the io.js merger as an educated guess at what enterprises would need. It was always a guess. The data from the past ten years just confirmed nobody was actually using odd releases in production.
What the old model actually looked like in practice
Every October, a new odd-numbered release dropped. Every April, a new even-numbered one did. Only the even versions graduated to LTS. So you'd get Node 20 (LTS), then Node 21 (use it if you want but it'll be EOL in 6 months), then Node 22 (LTS), and so on.
Most teams skipped the odd releases entirely. Companies running Node in production just waited for the even version to hit LTS and then planned their upgrade. The odd releases were basically an extended beta that the majority of the ecosystem ignored.
Meanwhile the maintainers — most of whom are volunteers — had to manage security releases across four or five active release lines simultaneously. Backporting fixes across that many branches is brutal. That's the real reason this change is happening, and it's a completely legitimate one.
The new model
Starting with Node 27, the cycle looks like this:
- October: Alpha phase begins. This replaces the early-testing role the odd releases used to serve. Signed, tagged builds, tested via CITGM (Canary in the Goldmine). Not for production. Semver-major changes are still allowed here.
- April: Official
X.0.0release. "Current" phase, six months of stabilization. - October: Promoted to LTS.
- ~30 months of LTS, then maintenance, then EOL.
Total support window per version: 36 months from first Current release.
Version numbers align with calendar year now too — 27.0.0 ships April 2027, 28.0.0 ships April 2028. Clean, predictable, obvious. Should've been this way from the start.
The alpha channel is the interesting part
This is what replaces the odd releases functionally. The alpha builds are signed and tagged (unlike nightly builds), run through CITGM which tests major open-source packages against them, and notify package authors if something breaks. The cadence is flexible — the Release Team decides how often to cut alphas based on how much has changed.
The target audience is library authors and teams that want to catch compatibility issues early. If you're only testing against LTS releases, you'll find out about breaking changes when your users do, which is not a great look.
So: if you maintain any npm packages with significant usage, set up CI against the alpha builds. The Node.js team is asking for this explicitly, and it's a fair ask given they're trying to reduce the last-minute scramble before each major release.
What this means for your upgrade cadence
For most teams running LTS in production, the practical impact is pretty minimal. You still upgrade roughly every two years to stay on a supported version. The overlap between LTS versions is preserved, so you're not forced to jump immediately.
The version numbers jump faster now on paper (27, 28, 29...) but that's cosmetic. What matters is the support timeline, and that's basically the same.
For library authors, it's actually better — one moving target per year instead of two, plus an alpha channel with proper tooling to catch problems before they hit users.
The real takeaway
This is a sustainability decision as much as a technical one. Node's maintainers burned time every year on releases that a tiny fraction of the ecosystem actually ran. Cutting that in half frees up real capacity for things that matter: security fixes, backports, quality work on the runtime itself.
It's also a rare case of a project course-correcting based on actual data rather than defending a decision made under different circumstances a decade ago. James Snell, who proposed the original schedule, explicitly said it was time to revisit whether it still made sense. It didn't. So they changed it.
Node 26 enters LTS in October 2026 and lives until April 2029. Node 27 alpha kicks off that same October. If you're planning any runtime upgrades in the next 18 months, factor in that the version numbering and release dates are shifting — but the underlying LTS guarantees you rely on aren't going anywhere.
Sources:
Comments
No comments yet. Be the first to comment.