summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSean McGivern <sean@mcgivern.me.uk>2017-11-09 14:09:38 +0000
committerSean McGivern <sean@mcgivern.me.uk>2017-11-09 14:09:38 +0000
commit5c51c3e164fc2cb9d1fdb102853b2294af122800 (patch)
tree93288124b5e97637a957f2fbe8f531b3e4b596ab
parentae434cccb2de4dacd5741b334869b7ee2d41849e (diff)
parent4d0add353832040470f8deada9dc651a9a6cb8ea (diff)
downloadgitlab-ce-5c51c3e164fc2cb9d1fdb102853b2294af122800.tar.gz
Merge branch 'docs/support-release-tools-132' into 'master'
Use the new simpler `Pick into X.Y` labels workflow after the 7th See merge request gitlab-org/gitlab-ce!15282
-rw-r--r--PROCESS.md38
1 files changed, 23 insertions, 15 deletions
diff --git a/PROCESS.md b/PROCESS.md
index 06963243b25..7c8db689256 100644
--- a/PROCESS.md
+++ b/PROCESS.md
@@ -141,21 +141,29 @@ the stable branch are:
* Fixes for security issues
* New or updated translations (as long as they do not touch application code)
-During the feature freeze all merge requests that are meant to go into the upcoming
-release should have the correct milestone assigned _and_ have the label
-~"Pick into Stable" set, so that release managers can find and pick them.
-Merge requests without a milestone and this label will
-not be merged into any stable branches.
-
-Fixes marked like this will be shipped in the next RC for that release. Once
-the final RC has been prepared ready for release on the 22nd, further fixes
-marked ~"Pick into Stable" will go into a patch for that release.
-
-If a merge request is to be picked into more than one release it will also need
-the ~"Pick into Backports" label set to remind the release manager to change
-the milestone after cherry-picking. As before, it should still have the
-~"Pick into Stable" label and the milestone of the highest release it will be
-picked into.
+During the feature freeze all merge requests that are meant to go into the
+upcoming release should have the correct milestone assigned _and_ the
+`Pick into X.Y` label where `X.Y` is equal to the milestone, so that release
+managers can find and pick them.
+Merge requests without this label will not be picked into the stable release.
+
+For example, if the upcoming release is `10.2.0` you will need to set the
+`Pick into 10.2` label.
+
+Fixes marked like this will be shipped in the next RC (before the 22nd), or the
+next patch release.
+
+If a merge request is to be picked into more than one release it will need one
+`Pick into X.Y` label per release where the merge request should be back-ported
+to.
+
+For example, if the current patch release is `10.1.1` and a regression fix needs
+to be backported down to the `9.5` release, you will need to assign it the
+`10.1` milestone and the following labels:
+
+- `Pick into 10.1`
+- `Pick into 10.0`
+- `Pick into 9.5`
### Asking for an exception