Skip to content

Enforce a more strict policy for semver-major releases #1054

Closed

Description

@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

Activity

  1. RafaelGSS commented on Oct 30, 2024

    @RafaelGSS
    MemberAuthor

    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.

  2. BethGriggs commented on Oct 30, 2024

    @BethGriggs
    Member

    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.

  3. RafaelGSS commented on Oct 30, 2024

    @RafaelGSS
    MemberAuthor

    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).

  4. transferred this issue fromnodejs/TSCon Oct 30, 2024
  5. RafaelGSS commented on Nov 13, 2024

    @RafaelGSS
    MemberAuthor

    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.

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      Sponsor
      SponsoredKunjungi sekarang
      Promo