Announcement: Upcoming changes to the Engineer process for patch releases
Status 2023-05-17
See #2886 (comment 1394944647) for the latest status.
N.B. As of now, the maintenance policy has not been extended - we backport bug fixes for only the current stable release at any given time
Delivery is working to extend the GitLab maintenance policy to support bug fixes to the two previous monthly releases in addition to the current stable release, this means patch releases will change from releasing a single version package to releasing three package versions.
If you are a part of:
- An engineering group (part of any department that works with GitLab.com), or
- The product group,
this change has the potential of impacting your workflow.
What is changing?
GitLab engineers will be enabled to merge into stable release branches. With the extension of the maintenance policy, teams will be enabled to self serve when merging bug fixes to two previous minor versions of GitLab. This change is a step on the journey to shift this process left and empower stage teams and engineers to own their own changes end to end.
Before officially extending the maintenance policy and committing this extension to GitLab customers, Delivery will run an internal pilot during 15.10 and 15.11, aiming to gather feedback from development teams about this new patch release process.
When is this changing?
After 15.10 and 15.11 are released, the corresponding stable branches will be opened to GitLab engineers, allowing them to merge but fixes into the stable branch
Previous version
On **2023-03-22, once 15.10 is released, the `15-10-stable-ee` branch will be opened to GitLab engineers**, allowing them to merge bug fixes into the stable branch.~How this differs from the current engineer process for patch releases?
With the current patch release process, backporting a bug fix into the current version requires GitLab engineers to add the Pick into x.x
label to the respective merge request, starting on 15.10, engineers will be allowed to merge bug fixes into the current stable branch.
The Delivery team will support you with any questions you may have:
- Reach out to #releases on Slack,
- Make sure to refer to the runbook for the new patch release process,
- Take a look at the dedicated Delivery AMA.
FAQ
Where can I provide feedback?
Please add a comment on this issue with your feedback or questions. If it is urgent, reach out to #releases Slack channel.
Why is the maintenance policy being extended?
The patch release process relies completely on the release managers' availability, leading to a few patch releases, and in consequence, the rejection of backport requests. Extending the maintenance policy:
- Meets the company needs by being aligned with the uptick of requests to backport bug fixes to older releases or to support more releases than what is currently defined in the maintenance policy.
- Enables developers to start merging into stable release branches so that they can self-serve on bug fixes rather than relying 100% on release managers to get their changes into minor releases.
- Brings the patch release policy on par with the security release one.
What would be the guidelines for merging bug fixes into a stable branch?
Bug fixes can be backported to the current version, if:
- They have been previously merged into the GitLab default branch (
master
). - They have been deployed to GitLab.com.
- They are bug fixes. Per the maintenance policy guidelines, features can't be backported to previous versions.
Merge requests targeting a stable branch should:
- Target the current version, which would be, 15.11.
- Use the stable branch template and follow the checklist.
- Have a maintainer approval (only one approval is required).
- Execute the
package-and-test
pipeline to guarantee the bug fix is Quality compliant. Failures on this pipeline should be reviewed and approved by a Software Engineer in Test.
Please refer to the runbook for patch releases for additional details.
What projects and GitLab versions are being impacted by this?
Previous version
During this internal pilot, the projects under Managed Versioning, including the GitLab canonical project, and the current version (15.10) will be impacted. During the development cycle of 15.11, feedback from this internal testing will be evaluated to decide if upcoming stable branches will be opened to engineers as well.
During this internal pilot, the projects under Managed Versioning, including the GitLab canonical project, and the current version (15.11) will be impacted. During the development cycle of 16.0, feedback from this internal testing will be evaluated to decide if upcoming stable branches will be opened to engineers as well.
Does this impact the security release process for developers?
No, the security release process for developers stays the same.
Where can I learn more about the maintenance policy extension?
Take a look at the dedicated AMA about the maintenance policy extension and the following links