From 1f794603f741a33af6b213e6b2d8b426a8b3da6c Mon Sep 17 00:00:00 2001 From: Rich Trott Date: Tue, 2 Aug 2016 21:07:53 -0700 Subject: [PATCH] meta: clarify process for breaking changes Fixes: https://github.com/nodejs/node/issues/7848 --- COLLABORATOR_GUIDE.md | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/COLLABORATOR_GUIDE.md b/COLLABORATOR_GUIDE.md index 90d73e80e9679b..d8ab4dc625e42a 100644 --- a/COLLABORATOR_GUIDE.md +++ b/COLLABORATOR_GUIDE.md @@ -56,16 +56,23 @@ full responsibility for the change, defer to another Collaborator. Before landing pull requests, sufficient time should be left for input from other Collaborators. Leave at least 48 hours during the week and 72 hours over weekends to account for international time differences -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. +and work schedules. Trivial changes (e.g. fixing typographical errors in +documentation) 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.