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