meta: clarify process for breaking changes

Fixes: #7848 PR-URL: #7955 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Julien Gilli <jgilli@nodejs.org> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

Author: Trott

COLLABORATOR_GUIDE.md

@@ -60,12 +60,20 @@ and work schedules. Trivial changes (e.g. those which fix minor bugs
 or improve performance without affecting API or causing other
 wide-reaching impact) may be landed after a shorter delay.
 
-Where there is no disagreement amongst Collaborators, a pull request
-may be landed given appropriate review. Where there is discussion
+For non-breaking changes, if there is no disagreement amongst Collaborators, a
+pull request may be landed given appropriate review. Where there is discussion
 amongst Collaborators, consensus should be sought if possible. The
 lack of consensus may indicate the need to elevate discussion to the
 CTC for resolution (see below).
 
+Breaking changes (that is, pull requests that require an increase in the
+major version number, known as `semver-major` changes) must be elevated for
+review by the CTC. This does not necessarily mean that the PR must be put onto
+the CTC meeting agenda. If multiple CTC members approve (`LGTM`) the PR and no
+Collaborators oppose the PR, it can be landed. Where there is disagreement among
+CTC members or objections from one or more Collaborators, `semver-major` pull
+requests should be put on the CTC meeting agenda.
+
 All bugfixes require a test case which demonstrates the defect. The
 test should *fail* before the change, and *pass* after the change.