Share

One major per year, every major headed for LTS, and a new Alpha phase: here’s why Node.js is changing a release model that has been in place for more than a decade.

For more than ten years, Node.js releases have followed a rhythm that became familiar across the ecosystem: a new major every six months, even-numbered releases moving into Long-Term Support, and odd-numbered releases serving as shorter-lived Current lines.

That model brought something Node.js badly needed in 2015: predictability.

Between Node.js 6 in 2016 and Node.js 26 in 2026, the project shipped 21 major versions on that cadence. Enterprises knew when an LTS release was coming. Package maintainers knew when to start testing the next major. The Release Working Group had a clear lifecycle for Current, Active LTS, Maintenance, and End-of-Life releases.

But a release model designed for the Node.js ecosystem of 2015 eventually started showing its age.

Node.js is now preparing to move to a different model: one major release per year, every major eventually becoming LTS, and a six-month Alpha phase replacing the role previously played by short-lived odd-numbered releases.

This is not simply a change in version numbering.

It changes how breaking changes reach the ecosystem, how maintainers test upcoming releases, how security fixes are carried across supported branches, and ultimately how developers should think about Node.js versions.

Running an EOL Version of Node.js?

An unsupported runtime may continue working today while security, dependency compatibility, and operational risk accumulate around it.

Understand your application's upgrade risk and build a clear path to a supported Node.js release with the NodeSource Upgrade Program.

Assess Your Node.js Upgrade Risk →

The model Node.js has used since 2015

The current release strategy dates back to October 2015.

At the time, Node.js adopted a six-month major release cadence. Even-numbered releases would eventually receive 30 months of LTS support, while odd-numbered releases would remain Current for a much shorter period before reaching End-of-Life.

An even-numbered release therefore followed a predictable path:

Current → LTS → Maintenance → End-of-Life

An odd-numbered release had a very different role. It existed primarily as a place where the project could introduce changes, collect ecosystem feedback, and stabilize those changes before the next LTS release.

That distinction was important.

Odd-numbered releases were never really intended to become the default runtime for large production environments. They acted as a proving ground for the next generation of Node.js.

The globalThis.navigator change provides a useful example. It landed in Node.js 21, caused problems for libraries that used typeof navigator as part of browser detection, and gave the ecosystem time to react before Node.js 22 became LTS.

In other words, the odd release had a job:

surface breaking changes before they reached the version most companies would eventually deploy.

And for many years, that model worked.

So why change it?

The problem is not that the six-month model failed.

The problem is that some of the assumptions behind it are no longer as useful as they once were.

From the user side, the even/odd distinction creates a version landscape that can be surprisingly difficult to interpret.

At one point in October 2024, a developer looking at Node.js could reasonably encounter Node.js 18 in Maintenance, Node.js 20 in Maintenance, Node.js 22 moving into LTS, and Node.js 23 marked Current.

All of them looked like active Node.js releases.

But they did not carry the same recommendation for production use.

For developers who only deploy LTS releases, there is another problem: half of the changes between one LTS release and the next may have first appeared in a release they never used.

Moving from Node.js 22 LTS to Node.js 24 LTS, for example, does not mean reading one clean transition document. Historically, users have had to understand changes introduced across both the intermediate odd-numbered release and the following even-numbered release.

That makes upgrade planning harder than it needs to be.

The cost is not only on users

Every supported Node.js line also represents maintenance work.

A major release requires semver-major triage, release preparation, documentation, CI validation, ecosystem testing, binaries across supported platforms, release notes, backports, and continued maintenance.

Under the previous model, the project performed that major-release process twice every year.

Security releases make the cost even clearer.

During periods when four lines were simultaneously supported, one vulnerability could require four backports, four CI runs, and four coordinated releases—sometimes under embargo and on the same day.

That overhead becomes especially difficult to justify for a short-lived odd-numbered line that has already been superseded by a newer major.

The talk uses Node.js 23 as an example: Node.js 23.11.1 shipped as a security release in May 2025, only a week after Node.js 24.0.0 had already been released.

The project was still spending release and security-maintenance effort on a line whose replacement was already available.

Fewer supported lines also matters for security

The supported-version question becomes more important once a Node.js version reaches End-of-Life.

An EOL Node.js release does not simply stop receiving fixes.

The Node.js project no longer evaluates new vulnerabilities against those lines. As the presentation puts it, the distinction is not merely “we do not fix them”; EOL versions are no longer part of the regular vulnerability-assessment process.

That creates a gap that is easy to underestimate.

A vulnerability may be discovered and fixed in supported versions while an older release remains affected. Some issues can even exist specifically in an EOL line and therefore never result in an advisory targeted at that version.

And Node.js itself is only part of the runtime stack.

An EOL Node.js release can also carry aging versions of components such as OpenSSL, V8, npm, undici, ICU, and other dependencies.

At the same time, older runtimes do not disappear simply because their maintenance window ends.

The data presented at NodeConf EU shows that in July 2026, Node.js 18 and Node.js 20—both already EOL—still represented roughly one in six version-attributed Node.js downloads.

A simpler release model cannot eliminate outdated deployments. But it can make the supported path easier to understand.

The design constraints behind the new model

Changing the release cadence was not simply a matter of deciding to ship less frequently.

The Release Working Group first had to define what a replacement model needed to preserve.

The presentation identifies four constraints:

Predictability. Less maintenance overhead. A 30-month LTS period. Alignment with critical dependencies such as OpenSSL.

That last point is particularly important.

Node.js cannot choose its support lifecycle entirely in isolation. The runtime depends on technologies such as OpenSSL, and extending Node.js support far beyond the support window of those dependencies would require either maintaining them independently or performing disruptive dependency upgrades inside an existing release line.

That is one reason proposals for significantly longer Node.js LTS periods did not become the solution.

The eventual model was the result of an extended process: months of discussion, roughly 100 comments, multiple TSC and Release Working Group meetings, and two Collaboration Summits.

The new Node.js release model

The result is a substantially simpler structure.

Instead of two majors every year, Node.js will move to one major release per year, released in April.

Every major release will eventually become LTS.

The odd/even distinction disappears.

And during the six months preceding the next major, Node.js will use a new Alpha release phase.

The lifecycle becomes:

Alpha → Current → LTS

For a major release, Current lasts approximately six months, followed by the existing 30-month LTS window. Alpha provides an additional six-month pre-release period before the major formally ships.

One of the most important aspects of the change is what does not happen:

LTS is not getting shorter.

The new release model reduces the number of majors and supported branches without reducing the existing 30-month LTS period.

Every major becomes LTS

This is arguably the most developer-visible simplification.

There will no longer be a question such as:

“Is Node.js 29 an LTS release or one of the short-lived ones?”

Every major is intended to progress toward LTS.

The version number also becomes much easier to associate with time.

Under the planned model:

Node.js 27 corresponds to 2027. Node.js 28 to 2028. Node.js 30 to 2030.

That is a small change on paper, but it makes the version history far easier to reason about for users, platform teams, security teams, and tooling.

Externally, users will also have a simpler set of states to understand:

Current → LTS → End-of-Life

The distinction between Active LTS and Maintenance becomes primarily an internal backporting concern rather than something most Node.js users need to use as their mental model.

What is Node.js Alpha?

Alpha is perhaps the part of the new schedule that requires the most explanation.

It is not simply another name for a nightly build.

And it is not intended to be a production runtime.

Alpha exists to preserve an important property of the old odd-numbered releases: a place where breaking changes can reach real users and ecosystem maintainers before the next major becomes Current.

Semver-major changes are explicitly allowed during Alpha. That can include changes such as major V8 updates or the removal of deprecated APIs. Meanwhile, Current and LTS remain the stable paths where those breaking changes should no longer be introduced.

This also solves a less obvious release-engineering problem.

Node.js generally allows changes to move toward LTS only after they have spent time in a released line. With only one major per year, there would otherwise be a period between October and April with no Current release available to provide that real-world validation.

Alpha keeps that pipeline moving.

Unlike a nightly, an Alpha release is curated by a releaser. It has release testing, signing, tags, and a changelog. Reviewers can also prevent changes from reaching Alpha when they are not ready.

Nightlies still exist.

Alpha simply gives ecosystem maintainers something much closer to an actual Node.js release to test against.

Why Alpha matters to library maintainers

For most application teams that run LTS versions, the new model should require relatively little change.

For package and framework maintainers, Alpha is more significant.

Under the previous model, maintainers could add the latest odd-numbered Node.js release to CI and discover compatibility problems months before the next LTS.

Alpha now becomes that early-warning system.

If a breaking change reaches Alpha in October, maintainers have roughly six months to test it, report issues, update libraries, and prepare before the next major becomes Current in April.

That makes Alpha particularly relevant to framework authors, native addon maintainers, tooling vendors, CI providers, and libraries with broad Node.js version support.

The presentation summarizes the change neatly: application teams on LTS may see almost no operational difference, while library maintainers should consider adding Alpha to their CI matrices.

The transition starts with Node.js 26 and Node.js 27 Alpha

The new model does not begin with a sudden cutover.

Node.js 26 remains the final release line created under the previous model.

On October 28, 2026, two things are planned to happen on the same day:

Node.js 26 becomes LTS.

And:

v27.0.0-alpha.0.0.0 becomes the first Alpha release under the new model.

Node.js 27 itself does not become Current until April 2027.

From there, the yearly cadence begins to settle into place: Node.js 28 in April 2028, Node.js 29 in April 2029, Node.js 30 in April 2030, and so on.

That distinction matters, particularly for the upcoming release cycle.

Node.js 27 Alpha arriving in October 2026 should not be interpreted as a recommendation to move production workloads to Node.js 27.

For production users, Node.js 26 moving into LTS is the more relevant event.

Node.js 27 Alpha is primarily where maintainers, tool builders, and early adopters can start testing what comes next.

For the October campaign, I would definitely use this graphic somewhere. It prevents the biggest potential misunderstanding about the upcoming release.

A simpler model for a larger ecosystem

Node.js is not changing its release strategy because the previous one was unsuccessful.

Quite the opposite.

The twice-yearly model gave the ecosystem more than a decade of predictable releases and created a stable LTS system on which companies around the world continue to depend.

But the ecosystem around Node.js has changed.

There are more changes moving through the project, more infrastructure to maintain, more security work to coordinate, and a much larger population of developers and organizations trying to make sense of which runtime they should deploy.

The new release model tries to preserve the properties that matter most—predictability, LTS stability, ecosystem testing, and dependency alignment—while removing a release line that increasingly created more operational complexity than value.

The result is deliberately easier to explain:

One major a year. Every line is LTS. Nothing got shorter.

Fewer branches need to be maintained. Experimental and breaking work gets an explicit Alpha label. Every major has a clear path to LTS. And the version number itself starts to behave more like a calendar.

For application developers, that should mean fewer release lines to reason about.

For maintainers, Alpha provides a clearer place to test the future.

And for the Node.js project itself, it reduces the number of simultaneous branches that need releases, backports, and security maintenance.

The release schedule is changing.

The goal, however, remains the same: make Node.js predictable enough for production while still giving the ecosystem room to evolve.