Blog: Evolving the Node.js Release Schedule

[UlisesGascon]

Preview url: https://nodejs-org-git-fork-ulisesgascon-release-announcement-openjs.vercel.app/en/blog/announcements/evolving-the-nodejs-release-schedule

Objective

This is an initial draft of the blog post, intended to collect feedback and iterate until we have a clear plan for communicating the release schedule change.

Explain to the users that we are planning a change in the Release Schedule starting on Node@27 and provide context on how the schedule works in general lines and the motivation for this change.

Context

We have been discussing this topic for a while in nodejs/Release#1113, nodejs/Release#953 and at the Collaboration Summit Chesapeake 2025.

The goal of this post is to communicate the change clearly to users as part of the messaging around Node 26.x, since the new plan will take effect starting with Node 27.x. We decided to write this blog post during our last Release WG meeting.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
nodejs-org	Ready	Preview	Feb 24, 2026 5:33pm

[github-actions]

👋 Codeowner Review Request

The following codeowners have been identified for the changed files:

Team reviewers: @nodejs/releasers @nodejs/nodejs-website

Please review the changes when you have a chance. Thank you! 🙏

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.15%. Comparing base (f11d90f) to head (23ce3d1).
⚠️ Report is 16 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8631      +/-   ##
==========================================
+ Coverage   75.01%   75.15%   +0.14%     
==========================================
  Files         103      104       +1     
  Lines        9068     9103      +35     
  Branches      315      314       -1     
==========================================
+ Hits         6802     6841      +39     
+ Misses       2264     2260       -4     
  Partials        2        2              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[UlisesGascon]

This is just a placeholder, no idea when makes sense to publish it.

[RafaelGSS]

Let's align it with Kylie and Robin. We should create an official tweet using Node.js account along with it.

[gurgunday]

lgtm

[RafaelGSS]

Despite those changes, I think we need to mention that it's up to the release team to define what the rules will be to ship semver-major commits in alpha versions.

[Renegade334]

It's a nice coincidence, but not sure this is worth stating here; it's not a stated objective or an explicit commitment of the new release plan.

[RafaelGSS]

Final nits, let's coordinate with social team to publish it!

[RafaelGSS]

Let's align it with Kylie and Robin. We should create an official tweet using Node.js account along with it.

[aduh95]

From what I understand from https://ubuntu.com/about/release-cycle, using Interim might not be a wise choice since Ubuntu seems to be using it only for releases that do not get long-term support (i.e. it would fit the current schedule's odd releases, but the new one no longer have those). So if we release 27.0.0 as Interim, it's actually sending the wrong signal.

Wdwt about "Latest"?

Suggested change

	| Interim | 6 months | Apr to Oct. Stabilization |
	| Latest | 6 months | Apr to Oct. Stabilization |

[MikeMcC399]

The exact comparison with Ubuntu is tricky, because their Interim releases are killed and renumbered as LTS releases. Ubuntu LTS releases are LTS from the first day of release. https://ubuntu.com/about shows that pictorially.

Beta would not be a good term either.

Maybe just call it what it is: "Stabilization" instead of "Interim", if the term "Interim" may be misinterpreted? (Except that's a long word!)

[UlisesGascon]

what about using Current (23ce3d1)? Maybe is less confusing as we use a term that is already known by our users? I you don't agree I can drop that commit 👍 .

Super open to suggestions anyway, but I agree that maybe Interm is not clear enough. While I like "Stabilization" maybe is translating the message that the release is not yet ready? but at the same time we finished Alfa but there is no Beta 🫤

[Waldenesque]

I suggest "Preview."

People heavily involved in open source speak so much English they're like native speakers, but that's not true for all developers. I expect a term like "pilot" would risk confusion for non-native English speakers, and can be ambiguous even if you are a native speaker. Maybe "promotion" since a new release is being promoted to LTS status. That's not too exotic, but it's not too familiar either, and feels subtle even for native speakers.

Perhaps "preview" is the least bad term. It borrows from everybody on earth watching Hollywood movies so they know about previews. The movie itself is largely finished, but it's being prepared for distribution to a wide audience. If you watch a preview, you get a valid taste of what's coming, but you also know that it's still possible something might change before final release. Even for native speakers this offers more instant recognition than other terms, and for people with limited English skills it's likely the easiest term.

[Renegade334]

"Preview" suggests pre-release imo.

[Waldenesque]

I also thought about "Early," though I don't think that's been used by other software before, and it's vague. LibreOffice used to use the term "Fresh," though my own memory of confusion around that term partly triggered me when I saw this blog post. The problem in that case was they didn't explain anything clearly, so it was hard to understand how their releases worked (even though it wasn't actually complicated at all).

It's hard to find a word that strikes a good balance. Essentially the two channels (Alpha and Interim) are meant for library testing and application testing, right? Theoretically they could be called "Libtest" and "Apptest" which isn't pretty but certainly avoids confusion.

[Waldenesque]

Sorry to stir up trouble here but...

If the goal is to invite library authors to integrate Alpha releases into their CI, the term "Alpha" is... bad. Nobody outside the Node inner circle has any idea how much or how little the details of release channels will change, so they cannot know how they should interpret terminology. If the proposed "Alpha" channel is intended to replace odd-numbered Current releases, it's a misleading name. The word "alpha" has strong connotations with decades of precedent that contradict such usage. I doubt many people would expect "alpha" releases to be tested through Canary in the Goldmine.

For a very mature project like Node, I suspect Nightly builds from main are closer to what most think of as "alpha" software. Today's odd-numbered Current releases are more equivalent to release candidates or at least beta versions. If someone from a Java background just starting serious work with Node sees the term "alpha," without knowing this history or context they might think "buggy prototype" and ignore it completely. Yet the purpose of this channel is to attract attention from library authors, right?

The term "beta" tells library authors it's time for testing without having to read a blog post. Was that term avoided deliberately, perhaps to allow more wiggle room for occasional buggy releases in this channel? I suppose "testing" would be misleading, since although this is meant for testing of libraries, the subsequent channel is also meant for testing, by end-user developers before LTS for production. Maybe the best option is already right under everyone's noses from CITGM: call this channel "Canary."

I think the non-native English speaker concern is less relevant here, since library authors already have to deal with more troublesome terminology anyway (and probably get more practice speaking English). The biggest precedent most people will have for the term "canary" is the React channel used by Next.js. That's probably an acceptable association, since it roughly matches what the experience will be for Node: generally stable, but expect occasional breakage or bugs. The name "Canary" avoids any "flaky prototype" connotations of "alpha," yet appropriately warns people not to expect reliable stability either.

After "Canary" to attract library authors, "Preview" would attract attention from early adopters (as opposed to those who stay on the older LTS). Imagine the viewpoint of Java, C#, Go, Rust, C++, Python and PHP developers, and hope for a match between their natural expectations and the future release channels being proposed for Node. I suspect "Canary" to "Preview" to "LTS" is less confusing or misleading than many other possibilities.

[RafaelGSS]

If the proposed "Alpha" channel is intended to replace odd-numbered Current releases

That's not the intention, Alpha releases can be very different from Current releases as we can ship semver-majors on it.

I wouldn't be opposed to a different term, but Beta or Canary doesn't seem different from Alpha in my experience - all of them tell the same: It's an experimental version, subject to break.

[Waldenesque]

This is a direct quote from the blog post draft:

The Alpha channel replaces odd-numbered releases.

So presumably that wording should be adjusted?

I think this perception of terminology is a difference between experts and everybody else. When you reach a certain level of expertise, you realize there isn't really a fundamental difference between categories like "alpha" or "beta" or whatever. But outside that circle of expertise, those words have a lot more subjective impact. I think "alpha" has stronger implications than experts realize.

[MattIPv4]

I personally think Alpha is also fine, it clearly communicates that the releases may still contain breaking changes, and that folks shouldn't rely on them for day-to-day use. We're explicitly stating that library authors are encouraged to test against these releases, whatever their perception of Alpha may be.

If there is really that much concern about the specific word being used, I could see Canary being a fine alternative, as it even more directly has connotations to being a release that we want library authors and such to test.