doc: revise "Breaking Changes" section of Collaborator Guide

Simplify material about TSC approval for breaking changes. Omit extraneous material explaining that purely additive changes are not breaking changes. PR-URL: #25071 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Anto Aravinth <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Yuta Hiroto <[email protected]> Reviewed-By: James M Snell <[email protected]>
nodejs · Dec 25, 2018 · 4561e2c · 4561e2c
1 parent 3f82144
commit 4561e2c
Showing 1 changed file with 2 additions and 7 deletions.
diff --git a/COLLABORATOR_GUIDE.md b/COLLABORATOR_GUIDE.md
@@ -242,8 +242,8 @@ For undocumented APIs that are public, open a pull request documenting the API.
 
 ### Breaking Changes
 
-Backwards-incompatible changes may land on the master branch at any time after
-sufficient review by Collaborators and approval of at least two TSC members.
+At least two TSC members must approve backward-incompatible changes to the
+master branch.
 
 Examples of breaking changes include:
 
@@ -254,11 +254,6 @@ Examples of breaking changes include:
 * altering expected timing of an event
 * changing the side effects of using a particular API
 
-Purely additive changes (e.g. adding new events to `EventEmitter`
-implementations, adding new arguments to a method in a way that allows
-existing code to continue working without modification, or adding new
-properties to an options argument) are semver-minor changes.
-
 #### Breaking Changes and Deprecations
 
 With a few exceptions outlined below, when backward-incompatible changes to a