Skip to content
Browse files

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 <>
Reviewed-By: Anto Aravinth <>
Reviewed-By: Richard Lau <>
Reviewed-By: Colin Ihrig <>
Reviewed-By: Luigi Pinca <>
Reviewed-By: Yuta Hiroto <>
Reviewed-By: James M Snell <>
  • Loading branch information
Trott committed Dec 18, 2018
1 parent 19a9205 commit 3edc1c917b6f678b9146b99daf91cc478cd0e8c3
Showing with 2 additions and 7 deletions.
  1. +2 −7
@@ -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

0 comments on commit 3edc1c9

Please sign in to comment.