Enforce a more strict policy for semver-major releases

[RafaelGSS]

Is there a way to avoid things like: nodejs/node#54160 (resulting in nodejs/node#55527)?

I think to guarantee better stability across semver-major releases we should stop landing semver-major PRs a month prior to the release date. It will make RC more easy to test and we possibly have more time to identify those errors across libraries. We also publish the release candidate 2 weeks prior to the official release.

What unfortunately happens is that we tend to land a bunch of semver-major PRs a week or two prior to the major release and that makes assessment really hard. I've been doing the last 4 semver-major releases and I have to say that's frustrating because:

• It's very hard for the releaser to identify it in the proposal
• Our CITGM/CI isn't reliable enough (IMHO) to guarantee such stability

Although semver-major releases are supposed to break a few things I really disagree with major breakages on old operations (without a real benefit)

I wonder if that's something nodejs/releasers should impose or TSC

cc: @nodejs/releasers @nodejs/tsc

[RafaelGSS]

Note we have the following policy for releaser:

The TSC should be informed of any SEMVER-MAJOR commits that land within one month of the release. - https://github.com/nodejs/node/blob/main/doc/contributing/releases.md#major-releases

But it also mean: it's "ok" to land semver-major commits within one month of the release when a TSC member approves.

[BethGriggs]

The TSC should be informed of any SEMVER-MAJOR commits that land within one month of the release. - https://github.com/nodejs/node/blob/main/doc/contributing/releases.md#major-releases

Just some history, that statement originally required the releaser to gather approval/consensus from the TSC to land any new major within a month of the release. It was changed to 'inform the TSC' during the time I was handling major releases because it was incredibly difficult to gather responses from the TSC for each new major being pulled into the release candidates.

I wonder if that's something nodejs/releasers should impose or TSC

Based on prior experience, it feel it may be more successful to have nodejs/releasers impose that requirement - as a smaller, generally very responsive group, and a group that more often makes the calls around stability/risk.

[RafaelGSS]

Thanks for jumping in @BethGriggs! I agree, I'll move this issue to nodejs/releasers group and add the tsc-agenda just for visibility. I think that's a decision that needs to be made for Node.js 24 (LTS).

[RafaelGSS]

I'm closing it as nodejs/node#55732 has been landed. I'll be working on the Node.js 24 release and seeing how this process works in practice.