Node.js Implements Stricter Policies for Semver-Major Pull Requests Ahead of Release Deadlines

This week the Node.js project is taking steps to bolster the stability and reliability of its major releases. In response to ongoing challenges and community feedback, the Node.js team has introduced a stricter policy governing semver-major pull requests. This update aims to enhance the stability of upcoming releases, particularly during the critical Release Candidate (RC) phase.

What’s Changing?#

Moving forward, any SEMVER-MAJOR PR that lands on the default branch within one month prior to a major release date will not be included in the new major staging branch unless there is explicit consensus from the Node.js release team. This policy ensures that significant changes are thoroughly vetted before being incorporated into the final release stages.

Why the Change?#

Over the past few major releases, the Node.js team has observed that the influx of semver-major PRs in the weeks leading up to a release can introduce unforeseen bugs and compatibility issues. Rafael Gonzaga, Node.js TSC delegate and key contributor to the project, highlighted these concerns in Issue #1054:

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

Gonzaga cited a recent bug fix in paths with trailing slashes that ended up having to be reverted due to the implementation introducing regressions in prominent projects.

These and other previous challenges prompted the need for a more controlled approach to managing major changes, ensuring that each release maintains the high standards expected by the Node.js community.

Major releases often introduce breaking changes that can significantly impact developers and applications relying on Node.js. By restricting the inclusion of semver-major commits during the final month before a release, the Node.js team aims to enhance stability by:

• Allowing for Comprehensive Testing: Additional time is allocated for rigorous testing of the release candidate, helping to identify and address potential issues before the official release.
• Protecting LTS Lines: Long-Term Support (LTS) versions are critical for many production environments. This policy helps safeguard these lines from major disruptions that could arise from last-minute changes.

The introduction of this policy has been met with broad support from the Node.js community and its maintainers.

“My goal with this doc change is to clarify/enforce that the last sync between main and vN.x will be a month prior to the release,” Gonzaga said. “I might be using the wrong word, but I do think ‘enforce’ should mean we won't include any semver-major PR that was merged into main less than a month of the release date (except in specific situations as mentioned in the doc too).”

Ahead of Node.js v24.0.0, Gonzaga said those responsible for the release are aiming to send release candidates out one month before the official release date, in order to enable library maintainers and companies to transition to new versions more quickly when the final release occurs.

By implementing this stricter policy, Node.js reinforces its dedication to maintaining a robust and dependable platform for developers worldwide. As the project evolves, such measures are crucial in balancing innovation with reliability, ensuring that Node.js remains a trusted foundation for countless applications and services.

For more details on the policy changes, which were merged less than 24 hours ago, you can view the pull request #55732 on GitHub.