Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

doc: revise breaking changes material in COLLABORATOR_GUIDE #25730

Closed
wants to merge 1 commit into from
Closed

doc: revise breaking changes material in COLLABORATOR_GUIDE #25730

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 2 additions & 12 deletions COLLABORATOR_GUIDE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -270,24 +270,14 @@ For more information, see [Deprecations](#deprecations).
#### Breaking Changes to Internal Elements

Breaking changes to internal elements may occur in semver-patch or semver-minor
commits. Collaborators should take significant care when making and reviewing
such changes. An effort must be made to determine the potential impact of the
change in the ecosystem. Use
commits. Take significant care when making and reviewing such changes. Make
an effort to determine the potential impact of the change in the ecosystem. Use
[Canary in the Goldmine](https://github.com/nodejs/citgm) to test such changes.
If a change will cause ecosystem breakage, then it is semver-major. Consider
providing a Public API in such cases.

#### When Breaking Changes Actually Break Things

Because breaking (semver-major) changes are permitted to land on the master
branch at any time, at least some subset of the user ecosystem may be adversely
affected in the short term when attempting to build and use Node.js directly
from the master branch. This potential instability is why Node.js offers
distinct Current and LTS release streams that offer explicit stability
guarantees.

Specifically:

* Breaking changes should *never* land in Current or LTS except when:
* Resolving critical security issues.
* Fixing a critical bug (e.g. fixing a memory leak) requires a breaking
Expand Down