Skip to content

NODE_MODULE_VERSION bumps on Alpha/Current #1194

Open

Description

@RafaelGSS

Since nodejs/node#64196, V8 updates that bump NODE_MODULE_VERSION may land during the Alpha and Current phases of a release line, as long as the ABI change is documented in the release notes.

This came up while reviewing the v27.0.0-alpha proposal (nodejs/node#67062)

My suggestion is: For v27 keep 27.0.0-pre label throughout the Alpha phase, since alpha builds come from the same tree as main and the NMV can still change before 27.0.0. The 27.0.0 release commit will drop the -pre suffix as usual. This issue is about what happens after that.

Current state

main and v27.x both carry:

{ "modules": 153, "runtime": "node", "variant": "v8_15.6", "versions": "27.0.0-pre" },
{ "modules": 152, "runtime": "node", "variant": "v8_15.5", "versions": "27.0.0-pre" },
{ "modules": 151, "runtime": "node", "variant": "v8_15.2", "versions": "27.0.0-pre" },

The alpha ships NMV 153 and does not change the file. The next bump on main will be labelled 28.0.0-pre.

Questions

  1. If a V8 update bumps the NMV on v27.x after 27.0.0 (for example to 155
    in 27.2.0), how should the registry describe 153 and 155? The versions
    field is a free-form string and old entries already use ranges such as
    ">=1.1 <2", so one option is ">=27.0.0 <27.2.0" and ">=27.2.0".
    Another is to keep a single version per entry and allow several entries
    for the same major.

  2. Where should the ABI change be called out in the release notes, and
    should the semver-major label stay on the PR once it is backported to a
    Current line as a minor?

Once we agree, I'll send a PR updating releases.md and, if needed, the
registry format.

cc @nodejs/releasers

Activity

  1. aduh95 commented on Oct 29, 2026

    @aduh95
    Contributor

    I don't think it makes sense for main to keep NODE_MAJOR_VERSION set to 27 major number once it will have diverged from 27.x (which is as soon as 27.0.0-alpha.0.0.0 will have landed): it's two different branches, it makes more sense to use separate version numbers.
    Regarding keeping 27.0.0-pre: I assume that would make life of a user trying to figure out what versions will work harder. I don't know how much of a problem that would be.

    Another solution would be to use REPLACEME (or keep 28.0.0-pre and replace that when we prepare a new Alpha release), similar to how we treat the YAML comments in the docs.

  2. legendecas commented on Oct 29, 2026

    @legendecas
    Member
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions