Proposal - change the prerelease phase name to something else

[trivikr]

Is your request related to a problem? Please describe.

In the blog post Evolving the Node.js Release Schedule, the Node.js release team announced the move from two major releases per year to one. The announcement also included Alpha phase for early testing from October to March which allows semver-major versions.

Although it's called Alpha phase and it'll start with alpha.0 release, I believe we'll release rc versions closer to stable release as they were done before.

Here are the rc versions for v25:

Version	Release Date
v25.0.0-rc.0	Sep 18, 2025
v25.0.0-rc.1	Oct 9, 2025
v25.0.0-rc.2	Oct 13, 2025
v25.0.0	Oct 15, 2025

If rc versions are released in Alpha phase, it can create confusion.
Users may wonder why the prerelease tag rc instead of alpha in the Alpha phase?

I believe rc releases will exclude semver-major changes.
It might create confusion with Alpha phase which allows semver-major changes.

Example for v27 (dates are approx)

Version	Release Date	Phase	semver-major allowed?
v27.0.0-alpha.0	Oct 15, 2026	Alpha	Yes
v27.0.0-alpha.1	Oct 30, 2026	Alpha	Yes
// More alpha releases twice a month
v27.0.0-alpha.9	Feb 28, 2027	Alpha	Yes
v27.0.0-rc.0	Mar 15, 2027	Alpha	No
v27.0.0-rc.1	Mar 28, 2027	Alpha	No
v27.0.0-rc.2	Apr 9, 2027	Alpha	No
v27.0.0	Apr 15, 2027	Current	No

For the above table, the confusion may happen in March 2027 when rc releases start appearing in the Alpha phase.

Describe the solution you'd like

Give a different name to the prerelease phase. Some options I can think of:

• prerelease: aligns with semver. It's a little verbose though.
• preview: a shorter version of prerelease. This is often used by the enterprise, including Amazon, Microsoft, Google, Adobe, etc.
• beta: Chrome, whose V8 engine Node.js includes, uses Beta
• dev/canary/nightly: these terms are used for a more unstable versions, and may not be appropriate.
• insiders: some Microsoft products use this label.

From the options provided above, preview would be a better name for the prelease phase. Since the blog post highlights the needs of the enterprises twice already, the preview name also aligns with it.

Additional context

Prior discussion: nodejs/nodejs.org#8631 (comment)

[aduh95]

it'll start with alpha.0 release

I wouldn't be so sure, I don't think alpha.0 would be very useful. I think a better naming convention would be to have 27.0.0-alpha.0.0.0 so we can still communicate the semverness of a release during the alpha period.

If rc versions are released in Alpha phase, it can create confusion.

It's unclear if rc would serve a purpose if there's already an alpha channel, more likely than not we won't need them anymore.

I believe rc releases will exclude semver-major changes.
It might create confusion with Alpha phase which allows semver-major changes.

If a change makes it to the release line (either in an alpha, rc, current, LTS release or whatever name we choose), it stays there for the follow up release. If you look at the 24.0.0-rc releases, you'll see that e.g. the version of V8 changes (which is a major breaking change), and it hasn't been a problem.

---

Anyway, if I had to vote, I would go either alpha or canary. I guess beta would also be fine.

Another solution would be to not include any label in the version string, e.g. Node.js 27.0.0-0.0.0 (Alpha) would be the first pre-release, Node.js 27.0.0 (Current) would be the first "stable" release. That way, we could easily change the label without affecting the ecosystem

[RafaelGSS]

I would also avoid including rc here, since it represents a candidate that will eventually become the official release. Once we issue an rc for a semver-major release, nothing typically changes between rc.$last and vX.0.0. In contrast, alpha releases are expected to keep changing before reaching that stage.

[trivikr]

Anyway, if I had to vote, I would go either alpha or canary. I guess beta would also be fine.

I did came across beta multiple times in the projects related to Node.js

• v8 calls their biweekly channel beta. However, since they don't follow semver, their beta release becomes stable.
• Chrome has beta releases in all their channels. But it's similar to v8.

The canary is also used by Chrome and v8. But it means a daily release, and not fortnightly release which Node.js is aiming to do. Other words used for daily releases are dev, insiders and nightly.

Another solution would be to not include any label in the version string, e.g. Node.js 27.0.0-0.0.0 (Alpha) would be the first pre-release

This can be made short as 27.0.0-0. However, the lack of prerelease word can make some users assume that it's stable though.
I recently remembered knip has used it. When I read the release number in a social media post, I assumed for a second that stable version was out.

---

If enterprise support is a priority, I'd recommend renaming the phase to preview for reasons explained in the issue description. The prerelease tag could follow suit, like 27.0.0-preview.0, though since end users type this directly, we should align with established semver conventions.

[trivikr]

I would also avoid including rc here, since it represents a candidate that will eventually become the official release

I looked at the Proposal 1 which @aduh95 shared in another discussion.

Can we still have rc releases in March, which allows only selective semver-major changes?

• security fixes
• V8 update
• one-time exception granted by the TSC

In the proposal, they're listed as beta

Version	Tentative Date	Type of changes
v27.0.0-alpha.0	2026-10-20	Branch-off
...	...	...
v27.0.0-alpha.10	2027-03-09	most changes
v27.0.0-beta.0	2027-03-23	most changes + V8 update
v27.0.0-beta.1	2027-04-06	semver-minor only + V8 update
v27.0.0	2027-04-20	semver-minor only
v27.x.x	2027-05-04	…

The rc (release candidate) is the perfect middle ground for users. It's more polished and stable than an alpha, it gives Node.js users a reliable preview to test their applications and libraries against before the final release lands.

[aduh95]

This can be made short as 27.0.0-0

Not really, or rather not without scarifying the semver information. I.e. it's unclear what's the "semverness diff" between 27.0.0-0 and 27.0.0-1, while it's clear for 27.0.0-0.0.0 and 27.0.0-0.1.0.

However, the lack of prerelease word can make some users assume that it's stable though.

That almost sounds like a feature, not a bug. Those release are aimed to be "stable", depending what you mean by "stable"

[ljharb]

Generally, any diff between prereleases is considered "maybe semver-major", so indeed the granularity is lost.