Enforce a more strict policy for semver-major releases #1054
Comments
|
Note we have the following policy for releaser:
But it also mean: it's "ok" to land semver-major commits within one month of the release when a TSC member approves. |
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.
Based on prior experience, it feel it may be more successful to have |
|
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). |
Co-authored-by: Antoine du Hamel <[email protected]> PR-URL: #55732 Refs: nodejs/Release#1054 Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ulises Gascón <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Marco Ippolito <[email protected]> Reviewed-By: Richard Lau <[email protected]>
|
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. |
Co-authored-by: Antoine du Hamel <[email protected]> PR-URL: #55732 Refs: nodejs/Release#1054 Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ulises Gascón <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Marco Ippolito <[email protected]> Reviewed-By: Richard Lau <[email protected]>
Co-authored-by: Antoine du Hamel <[email protected]> PR-URL: nodejs#55732 Refs: nodejs/Release#1054 Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ulises Gascón <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Marco Ippolito <[email protected]> Reviewed-By: Richard Lau <[email protected]>
Co-authored-by: Antoine du Hamel <[email protected]> PR-URL: nodejs#55732 Refs: nodejs/Release#1054 Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ulises Gascón <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Marco Ippolito <[email protected]> Reviewed-By: Richard Lau <[email protected]>
Co-authored-by: Antoine du Hamel <[email protected]> PR-URL: #55732 Refs: nodejs/Release#1054 Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ulises Gascón <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Marco Ippolito <[email protected]> Reviewed-By: Richard Lau <[email protected]>
Co-authored-by: Antoine du Hamel <[email protected]> PR-URL: #55732 Refs: nodejs/Release#1054 Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ulises Gascón <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Marco Ippolito <[email protected]> Reviewed-By: Richard Lau <[email protected]>
Co-authored-by: Antoine du Hamel <[email protected]> PR-URL: #55732 Refs: nodejs/Release#1054 Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ulises Gascón <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Marco Ippolito <[email protected]> Reviewed-By: Richard Lau <[email protected]>
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:
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
The text was updated successfully, but these errors were encountered: