Node.js New Release Schedule:
One Major Per Year, Alpha Channel & What It Means

Introduction

The Node.js project just announced the first major change to its release schedule in about ten years. Starting in October 2026, Node.js moves from two major releases per year to one, version numbers will line up with the calendar year, every release becomes LTS, and there is a brand new Alpha channel for early testing.

If that sounds like a lot, here is the reassuring part up front: if you are like most people and you only ever upgrade to LTS versions, very little actually changes for you beyond the version numbers on the box. But the change is well thought out, and it is worth understanding so you can plan your upgrades with confidence.

In this guide, we will look at what is changing, why the project decided to do it, and what it means for you in practice — whether you run Node.js in production, maintain a library, or are just trying to keep track of which version you are supposed to be on.

Quick Overview: What's Changing

If you only have a minute, here is the whole thing in six bullets:

• One major release a year, not two. Each new major lands every April and is promoted to LTS in October.
• Year-based version numbers. Node.js 27 ships in 2027, Node.js 28 in 2028, Node.js 29 in 2029, and so on.
• Every release becomes LTS. The odd/even distinction is gone. Node.js 27 will become LTS, and so will every release after it.
• A new Alpha channel (for example 27.0.0-alpha.1) gives library authors and CI pipelines a six-month window to test breaking changes early.
• Support windows stay familiar: LTS is still around 30 months, with roughly 36 months from first release to end of life.
• It starts in October 2026. Node.js 26 is the last release under the old model, and Node.js 27 is the first under the new one.

How Node.js Releases Work Today (Pre-October 2026)

Before we get into what is changing, it is worth a quick refresher on how things have worked up to now. Under the current model, Node.js ships two majors a year: one in April and one in October. Every new major spends six months on the Current line — the stabilization period where library authors test compatibility.

After those six months, the version's fate depends on a single rule: odd-numbered releases (like 19, 21, 23, 25) reach end of life and are never promoted. Even-numbered releases (like 20, 22, 24, 26) are promoted to Active LTS and supported for a total of 30 months.

If you have ever had to explain that rule to someone new, you already know the problem with it. The odd/even rule is a genuine stumbling block for newcomers — it feels obvious once you know it and completely arbitrary until you do. This is the primary pain point the new model addresses.

What Changes from October 2026

The new model keeps everything that worked about the old one — a predictable cadence, a stabilization period, long support windows — and removes the parts that caused friction. Let us go through the four headline changes.

One Major Release a Year

Instead of two majors a year, there will be one. The rhythm is simple: a new major enters Current in April, and it is promoted to LTS in October of the same year. Half as many versions to track, and the dates never move.

Year-Based Version Numbers

This is the most visible change. From now on, the major version number lines up with the calendar year of the release: Node.js 27 ships in 2027, Node.js 28 in 2028, Node.js 29 in 2029, and so on. The number now tells you, at a glance, how old a runtime is.

There is also a happy coincidence that makes this line up so cleanly. Right now the major version (26) already matches the last two digits of the year (2026). Moving to exactly one release a year keeps them in lockstep from here on.

Every Release Becomes LTS

With one release a year, there is no longer any need for the odd/even dance. Every release becomes LTS. Node.js 27 will become LTS, Node.js 28 will become LTS — every single year.

This change reflects reality. The Node.js team openly acknowledged that adoption of odd-numbered releases has historically been very low — most users simply waited for the next LTS and skipped the odd ones entirely. If the releases people actually run are the LTS ones, then making every release an LTS is just the model catching up with reality.

A New Alpha Channel

Here is the clever bit. The odd releases were not only about version churn — they also served a real purpose: they gave library authors a real, tagged build to test breaking changes against. Drop the odd releases naively and you would lose that early-warning system.

The project is replacing them with something better: a dedicated Alpha channel. For the six months before a version becomes Current (October to March), there will be signed, tagged Alpha builds using the standard semver prerelease format like 27.0.0-alpha.1 and 27.0.0-alpha.2. These builds allow semver-major (breaking) changes and go through real quality gates — they are tested through CITGM, the project's "Canary in the Goldmine" tooling.

Alpha builds are explicitly not for production. They are a testing ground for the people who need to catch breaking changes early.

The New Release Lifecycle

Putting it all together, every release now flows through the same four phases:

That is roughly 36 months from a version's first Current release to its End of Life, keeping the support window very close to what we have today.

Node.js 26 vs Node.js 27: The Transition

The cleanest way to see the shift is to compare the last release of the old world with the first release of the new one:

The Schedule Going Forward

Because the cadence is now so regular, you can read the schedule years into the future without a calendar. Each major enters Alpha in October, goes Current the following April, becomes LTS that October, and reaches end of life about three years after it first shipped:

Why the Project Is Doing This

A change like this is not made lightly. The honest, unglamorous truth is that Node.js is maintained largely by volunteers, and the old model asked a lot of them. Keeping security fixes flowing across four or five active release lines at once means a huge amount of backporting, testing, and coordination — and most of that effort went into release lines that comparatively few people were actually running.

The data backed this up on several fronts:

• Low odd-release adoption. Most users waited for LTS and skipped the odd releases entirely. The effort of maintaining them rarely paid off.
• Newcomer confusion. The odd/even rule is a genuine stumbling block for people new to the ecosystem.
• Sustainability. Fewer concurrent release lines means less backporting toil and more energy focused on the releases people depend on.

A volunteer-run project looking honestly at where its maintainers' time goes, and then choosing to cut its own busywork, is exactly the kind of responsible decision that keeps a project alive for another decade.

What It Means for You

If You Run LTS in Production

This is almost a non-event. Keep doing exactly what you do today: deploy LTS, upgrade to the next LTS when you have time to test, and enjoy not having to remember the odd/even rule ever again. The one thing to internalize is the new mental model: the version number is now the year, and every yearly release is one you can eventually run in production.

For a complete overview of what ships inside Node.js 26 — the last release under the old model — including the Temporal API, V8 14.6 features, and Undici 8, see my Node.js 26 Complete Guide.

If You Maintain a Library or Tool

This is where you have a real job to do. Please wire the new Alpha releases into your CI as early as you can. The whole point of the Alpha channel is to surface breaking changes before they reach the users who depend on you. If you only ever test on LTS, you will find out about breakage at the same time your users do — which is exactly the situation Alpha exists to prevent.

Add an Alpha test matrix to your CI configuration:

# .github/workflows/ci.yml
strategy:
  matrix:
    node-version:
      - '22'      # Current LTS
      - '24'      # LTS
      - '26'      # Latest LTS (after Oct 2026)
      - '27.0.0-alpha.1'  # Alpha channel

For a closer look at the Node.js Permission Model — a key security feature that graduated from experimental in Node.js 26 — see my Node.js Permission Model guide. And for a comparison with alternative runtimes, check my Deno 2.8 guide.

FAQ