Handle Node.js alpha releases - #26

There's still some debate on whether latest should point to the alphas

I'm surprised that this hasn't been figured out yet as part of the switch! I was also surprised to find that current in the standard Node.js github actions resolved to v27, I guess that's coming from nvm and that perhaps the ecosystem has decided this one for you already?

There's still some debate on whether latest should point to the alphas

I'm surprised that this hasn't been figured out yet as part of the switch! I was also surprised to find that current in the standard Node.js github actions resolved to v27, I guess that's coming from nvm and that perhaps the ecosystem has decided this one for you already?

• latest alias usage in Alpha phase #23
• Outdated definition for latest alias under https://nodejs.org/download/release node#67224
• latest points to Alpha by version managers / nodejs.org points to LTS node#67135

and a suggestion to have a separate next link:

• Request for next or latest-alpha alias to match Current / Alpha #25

@rvagg

As also mentioned in nodejs/node#67224 (comment)

The actions/setup-node team are addressing these related issues:

• Provide allow-prereleases (or similar) option for Node.js 27 Alpha actions/setup-node#1657
• latest & (current & node) install v27.0.0-alpha.0.0.0 not 26.13.0 actions/setup-node#1660

Although they may share alias names, they are not dependent on this PR. They make their own decision about what they term latest.

It makes the resolution of related issues more complex because each of the Node.js version managers is taking their own decisions about what aliases to use and how to interpret them.

There's still some debate on whether latest should point to the alphas

I'm surprised that this hasn't been figured out yet as part of the switch! I was also surprised to find that current in the standard Node.js github actions resolved to v27, I guess that's coming from nvm and that perhaps the ecosystem has decided this one for you already?

I did raise this issue in nodejs/Release#1171 on behalf of the docker-node repo back in August 2026. It didn't however receive any feedback (apart from my fellow docker-node team member), and so here we are, after the release of Node.js 27 Alpha and still discussing what latest should mean.

Users must be given a choice of whether they get Alpha versions installed or not. Nobody should accidently get an Alpha version.

Packages published to the npm registry use the convention of latest to mean stable, non-prerelease. If Node.js continues to use the same convention, there will be less user surprises.

Currently https://nodejs.org/download/release/latest/ serves Node.js 26.13.0. I support leaving it this way, so it points to either the current version or LTS version, whichever one of those is the highest non-prerelease version. It should not point to any Alpha pre-release.

Currently https://nodejs.org/download/release/latest/ serves Node.js 26.13.0

I support using that as the standard, latest is non-alpha, current probably should mean the same which means negotiating with the github actions guys to make it so - they're just grabbing from index.json without semver parsing but they probably should make the distinction now that prerelease semver strings are excluded from the calculation. There is an "lts" field in index.json, you could put an "alpha" one in there too, although this would be redundant given the semver.

Unfortunately the definitions and usage are all over the place. According to https://github.com/nodejs/release#readme current is no longer a phase that always exists. It goes instead between lts and current. actions/setup-node at the moment is installing the Node.js 27 Alpha release if current is specified.

According to their response in actions/setup-node#1660 (comment) they're planning to change the effect of specifying latest, current and node so that the latest non-prerelease would be installed.

I'm in favor to not exclude Alpha releases from latest, folks who want stability should target lts/*. The way I see it, someone targeting latest does accept "semver instability", otherwise they would be using a semver-range, so I don't see an upside in adding more labels.

There would need to be a decision about the necessity to differentiate between the alpha phase of latest and the current phase of latest.

If everyone who selects latest is happy to get an Alpha release, then there is no need for an extra alias.

If there are users who don't want an Alpha release, but do want to track the otherwise latest release then an extra alias is going to be necessary. Tracking lts misses out on the current phase after the Alpha phase has transitioned to Current.

If everyone who selects latest is happy to get an Alpha release, then there is no need for an extra alias.

and .. by extension there was no need for this new "alpha" language, surely there's an original reasoning behind the switch to alpha from "current" that should make it easier to reason about these downstream changes?

If everyone who selects latest is happy to get an Alpha release, then there is no need for an extra alias.

and .. by extension there was no need for this new "alpha" language, surely there's an original reasoning behind the switch to alpha from "current" that should make it easier to reason about these downstream changes?

Alpha allows semver-major changes, so worst case, and with a 2 week cadence, this could mean breaking changes that often. In comparison, there shouldn't be any planned semver-major changes during a "current" phase, although in practice accidental breaking changes do occur.

The November 2026 security releases also did not include any Alpha release, and I'd assume this would true for future security releases as well.

So, there are stability differences between lts, Current and Alpha. Each of these should be individually selectable, whatever alias names are used.

Related to this PR, which would also create a new link https://nodejs.org/download/docs/latest-v27.x/, there is the issue that the docs aren't getting populated (see nodejs/release-cloudflare-worker#1093), so at the moment there is no generic link for finding the 27 Alpha documentation. See also nodejs/nodejs.org#9254

I would still suggest to go ahead with this PR.