Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
G
gitlab-ce
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
1
Merge Requests
1
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
nexedi
gitlab-ce
Commits
4d0add35
Commit
4d0add35
authored
Nov 08, 2017
by
Rémy Coutable
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Use the new simpler `Pick into X.Y` labels workflow after the 7th
Signed-off-by:
Rémy Coutable
<
remy@rymai.me
>
parent
07ab4ad6
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
23 additions
and
15 deletions
+23
-15
PROCESS.md
PROCESS.md
+23
-15
No files found.
PROCESS.md
View file @
4d0add35
...
@@ -141,21 +141,29 @@ the stable branch are:
...
@@ -141,21 +141,29 @@ the stable branch are:
*
Fixes for security issues
*
Fixes for security issues
*
New or updated translations (as long as they do not touch application code)
*
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
During the feature freeze all merge requests that are meant to go into the
release should have the correct milestone assigned _and_ have the label
upcoming release should have the correct milestone assigned _and_ the
~"Pick into Stable" set, so that release managers can find and pick them.
`Pick into X.Y`
label where
`X.Y`
is equal to the milestone, so that release
Merge requests without a milestone and this label will
managers can find and pick them.
not be merged into any stable branches.
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
For example, if the upcoming release is
`10.2.0`
you will need to set the
the final RC has been prepared ready for release on the 22nd, further fixes
`Pick into 10.2`
label.
marked ~"Pick into Stable" will go into a patch for that release.
Fixes marked like this will be shipped in the next RC (before the 22nd), or the
If a merge request is to be picked into more than one release it will also need
next patch release.
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
If a merge request is to be picked into more than one release it will need one
~"Pick into Stable" label and the milestone of the highest release it will be
`Pick into X.Y`
label per release where the merge request should be back-ported
picked into.
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
### Asking for an exception
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment