OSSForks/node
1
0
Fork 0
mirror of https://github.com/zebrajr/node.git synced 2025-12-06 00:20:08 +01:00
Code Issues Actions 8 Packages Projects Releases Wiki Activity

doc: revise breaking changes material in COLLABORATOR_GUIDE

Browse Source 
* Remove unnecessary paragraph explaining why Current and LTS have
  stability guarantees that master branch does not. (Leave material
  explaining what those stability guarantees are.)
* Upgrade advisory and passive "Collaborators should take significant
  care" to more direct "Take significant care".

PR-URL: https://github.com/nodejs/node/pull/25730
Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
This commit is contained in:
Rich Trott 2019-01-26 16:22:41 -08:00 committed by Myles Borins
parent 550af6d72f
commit 7ed29fc1e8
No known key found for this signature in database
GPG Key ID: 933B01F40B5CA946
1 changed files with 2 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
COLLABORATOR_GUIDE.md
View File

@ -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