Guidelines for release managers about the new patch release process
As part of extending the GitLab maintenance policy GitLab engineers will be enabled to merge into stable branches. To test this new strategy an internal pilot will be run allowing GitLab engineers to merge into the current stable branch (15-10-stable-ee
) while release managers prepare patch releases for the current version (15.10).
The purpose of this issue is to serve as a guide for release managers about the new patch release process and to gather feedback from them.
Guidelines for engineers can be found at #2886 (closed)
How to determine if a patch release is required?
Consider the patch release pressure information located in the release manager dashboard. The information is split into two sections: Summary and breakdown per version
Summary | Breakdown per version |
---|---|
![]() |
![]() |
To determine if a patch release is required, take a look at the "Summary" section:
- If the "S1/S2 pressure" is greater or equal to 2, priority merge requests are waiting to be patched, in this case, a patch release is strongly encouraged.
- If the "Total pressure" displays a considerable number of unreleased merge requests (e.g. 10), a patch release would be beneficial to reduce the pressure.
Additional considerations:
- When planning the patch release consider if there is a security release in progress, if there is, it will include the bug fixes, and in this case, release managers can either wait for the security release to be completed or create a dedicated patch release.
- To know what merge requests are waiting to be patched, take a look at the stable branch links
15.10 Stable branch links
Note on the Patch release pressure
Click to expand
Since we're in the process of establishing the new patch release process, the release manager dashboard still displays the old patch release pressure used by the old process. For this process, release managers should only consider the new patch release pressure that counts merged merge requests into stable branches.
Old patch release pressure | New patch release pressure |
---|---|
![]() |
![]() |
The data in both metrics are different:
- The old patch release process, on the left, counts the merge requests labeled with
Pick into x.x
, - While the new patch release process, on the right, counts the merge requests merged into stable branches based on severity.
How to start a patch release?
In the #f_upcoming_release
Slack channel execute the following command:
/chatops run release prepare
This command will create:
- An issue on the release/tasks repo with all the required steps to perform a multi-version patch release
- A blog post with the unreleased merge requests on the www-gitlab-com repository.
Release managers should follow the steps listed on the release/tasks
issue.
What is the process when a stable branch is broken?
Please refer to the failures on stable branch runbook.
Where can I read more information?
Feedback
Please add a comment on this issue with your feedback or questions.