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
This commit is contained in:
commit
5c51c3e164
1 changed files with 21 additions and 13 deletions
34
PROCESS.md
34
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
For example, if the upcoming release is `10.2.0` you will need to set the
|
||||
`Pick into 10.2` label.
|
||||
|
||||
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.
|
||||
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
|
||||
|
||||
|
|
Loading…
Reference in a new issue