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

PUBLICATION DATE: April 2nd

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 26, 2026 8:05pm

[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.14%. Comparing base (f11d90f) to head (1f5459f).
⚠️ Report is 23 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.14%   +0.12%     
==========================================
  Files         103      104       +1     
  Lines        9068     9103      +35     
  Branches      315      314       -1     
==========================================
+ Hits         6802     6840      +38     
+ Misses       2264     2261       -3     
  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.

[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.

EDIT:

I tried a thesaurus for ideas, but nothing else seems to be clearly better. The way @UlisesGascon has it right now with "Current" may be best. If there's no obvious improvement available, the least bad option is probably just to avoid introducing new terminology at all.

[UlisesGascon]

Updated publication date to April 2nd

[Copilot]

Pull request overview

This pull request introduces a blog post announcing a significant change to the Node.js release schedule, along with supporting infrastructure changes. Starting with Node.js 27 in 2027, the project will transition from two major releases per year to one annual release, with every release entering Long-Term Support (LTS). The change aims to improve volunteer sustainability and align with actual user adoption patterns.

Changes:

• New blog post explaining the release schedule evolution, including rationale, timeline, and impact on users
• New SVG diagram visualizing the new release schedule timeline
• New author entry "Node.js Releasers" in authors.json with associated test updates

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 6 comments.

File	Description
apps/site/pages/en/blog/announcements/evolving-the-nodejs-release-schedule.md	New blog post announcing the release schedule changes, explaining the "why" and "what's changing", with detailed timelines
apps/site/public/static/images/blog/announcements/2026-new-release-schedule.svg	Visual timeline diagram showing the new release schedule from 2026-2033
apps/site/authors.json	Added "Node.js Releasers" author entry for the Release Working Group
apps/site/util/tests/author.test.mjs	Updated test expectations to reflect the new author entry behavior

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The phrase "to not be backported" uses a split infinitive. While this is grammatically acceptable in modern English, "not to be backported" would be more traditional and slightly more natural. This is a minor stylistic suggestion.

Suggested change

	- during Pull Request review, reviewers add a label requesting the change to not be backported
	- during Pull Request review, reviewers add a label requesting the change not to be backported

[Copilot]

There's an inconsistency in the Alpha duration. The table at line 62 states "Alpha | 5 months | Oct to Mar", but counting from October to the following April is 6 months (October, November, December, January, February, March = 6 months). The timeline table also confirms this: Alpha begins Oct 2026, and Current release is Apr 2027, which is 6 months apart. Either the duration should be corrected to "6 months" or the date range should be adjusted to match "5 months".

Suggested change

	| Alpha | 5 months | Oct to Mar. Early testing, semver-major allowed |
	| Alpha | 6 months | Oct to Mar. Early testing, semver-major allowed |

[Copilot]

The total support duration calculation appears to be incorrect. According to the table above, Alpha is 5 months, Current is 6 months, and LTS is 29 months, which totals 40 months, not 35 months. However, if we're calculating from the first Current release (not from Alpha start), it would be 6 + 29 = 35 months. This should be clarified to specify "35 months from Current release to End of Life" or the calculation should be corrected to reflect the actual total time including Alpha.

Suggested change

	Total support: 35 months from release to [End of Life (EOL)](https://nodejs.org/en/about/eol).
	Total support: 35 months from first Current release to [End of Life (EOL)](https://nodejs.org/en/about/eol).

[Copilot]

The phrase "semver-major changes are allowed during Alpha" is mentioned twice in close proximity (lines 71 and 92). While line 71 mentions it as one characteristic and line 92 lists it in the "What to expect" section, this repetition could be condensed for better readability. Consider whether both mentions are necessary or if the information could be presented more concisely.

Suggested change

- Semver-major changes may land during this phase.

[Copilot]

The phrasing "Version numbers align with the year of the first Current release and transition to LTS" is ambiguous. The version number aligns with the year of the Current release (e.g., 27.0.0 in April 2027), not with when it transitions to LTS (October). Consider rewording to "Version numbers align with the year of the Current release" or "Version numbers align with the calendar year of their initial Current release" for clarity.

Suggested change

	- **Version numbers align with the year of the first Current release and transition to LTS**: 27.0.0 in 2027, 28.0.0 in 2028.
	- **Version numbers align with the calendar year of their initial Current release**: 27.0.0 in 2027, 28.0.0 in 2028.

[Copilot]

Adding a third author entry with the same id "nodejs" creates ambiguity in the author lookup system. The function getAuthorWithId finds the FIRST match based on object iteration order, which means "Node.js Releasers" will now be returned when querying by id "nodejs", changing the behavior from the previous expectation of returning "Node.js Technical Steering Committee". Consider using unique IDs for each author entry (e.g., "nodejs-release", "nodejs-tsc", "nodejs-project") to avoid this ambiguity and make the lookup behavior more predictable and maintainable.

Suggested change

	"id": "nodejs",
	"id": "nodejs-release",