From eb330c1034fb5236f118142f29cb408ebcabca55 Mon Sep 17 00:00:00 2001 From: Petr Viktorin Date: Tue, 20 Apr 2021 16:24:31 +0200 Subject: [PATCH 1/2] devcycle: Clarify doc & test changes in Beta & RC --- devcycle.rst | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/devcycle.rst b/devcycle.rst index 366636389..d0ffb4d70 100644 --- a/devcycle.rst +++ b/devcycle.rst @@ -185,9 +185,10 @@ Beta ---- After a first beta release is published, no new features are accepted. Only -bug fixes can now be committed. This is when core developers should concentrate -on the task of fixing regressions and other new issues filed by users who have -downloaded the alpha and beta releases. +bug fixes and improvements to documentation and tests can now be committed. +This is when core developers should concentrate on the task of fixing +regressions and other new issues filed by users who have downloaded the alpha +and beta releases. Being in beta can be viewed much like being in RC_ but without the extra overhead of needing commit reviews. @@ -204,8 +205,9 @@ Release Candidate (RC) A branch preparing for an RC release can only have bugfixes applied that have been reviewed by other core developers. Generally, these issues must be severe enough (e.g. crashes) that they deserve fixing before the final release. -All other issues should be deferred to the next development cycle, since -stability is the strongest concern at this point. +All other issues (including documentation and test changes) should be deferred +to the next development cycle, since stability is the strongest concern at this +point. You **cannot** skip the peer review during an RC, no matter how small! Even if it is a simple copy-and-paste change, **everything** requires peer review from From 7d39b1c409e16ce990be5251aa4a8b55613294c2 Mon Sep 17 00:00:00 2001 From: Petr Viktorin Date: Wed, 21 Apr 2021 11:40:09 +0200 Subject: [PATCH 2/2] Update devcycle.rst --- devcycle.rst | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/devcycle.rst b/devcycle.rst index d0ffb4d70..aba81d71e 100644 --- a/devcycle.rst +++ b/devcycle.rst @@ -205,9 +205,12 @@ Release Candidate (RC) A branch preparing for an RC release can only have bugfixes applied that have been reviewed by other core developers. Generally, these issues must be severe enough (e.g. crashes) that they deserve fixing before the final release. -All other issues (including documentation and test changes) should be deferred -to the next development cycle, since stability is the strongest concern at this -point. +All other issues should be deferred to the next development cycle, since +stability is the strongest concern at this point. + +While the goal is to have no code changes between a RC and a final release, +there may be a need for final documentation or test fixes. Any such proposed +changes should be discussed first with the release manager. You **cannot** skip the peer review during an RC, no matter how small! Even if it is a simple copy-and-paste change, **everything** requires peer review from