From 7c8d57d4a9ef3e86b15992f528328d83e699ccec Mon Sep 17 00:00:00 2001 From: Rich Trott Date: Sat, 26 Jan 2019 16:22:41 -0800 Subject: [PATCH] doc: revise breaking changes material in COLLABORATOR_GUIDE * 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 Reviewed-By: James M Snell Reviewed-By: Anto Aravinth Reviewed-By: Michael Dawson --- COLLABORATOR_GUIDE.md | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/COLLABORATOR_GUIDE.md b/COLLABORATOR_GUIDE.md index c3805d4a2c05f9..25fab70575ad46 100644 --- a/COLLABORATOR_GUIDE.md +++ b/COLLABORATOR_GUIDE.md @@ -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