Launch coordination: New monthly release process and extension on the maintenance policy

Context

⚠️ Due to engineering impact, this issue is on hold until Engineering leadership is aligned on the proposal.

---

In the Software Delivery ecosystem, two paramount GitLab release procedures are in the process of being redesigned:

• New monthly release schedule - The ongoing stable branch generation will be created one week earlier in the monthly release schedule to allow for thorough testing and timely backports, increasing the quality, safety, and reliability of the monthly release.
• Extension of the maintenance policy - Extends the bug fix support across all currently maintained releases, delivering a more reliable and consistent experience for GitLab customers.

Impact

Rolling out these activities will have important implications

1. The milestone when the new monthly schedule is introduced will be one week shorter (one-time effect). Features deployed to GitLab.com after the 2nd Wednesday of the month will not be part of the monthly release.
2. Per the new policy, bug fixes must be backported to the maintained versions

Both release processes have a high impact on GitLab engineering and product operations as well as on GitLab customers. The purpose of this issue is to design a plan to roll out these efforts, minimizing the impact across GitLab's strategic operations.

Launch Plan

Extension of the maintenance policy

Release	Item	Description	Key results
18.4	Soft launch of the extension of the maintenance policy	Foster adoption of the new policy across engineering.	First patch of 18.4 will open up stable branches to all GitLab maintainers Provide feedback to the work done on Improve merge experience of backport MRs Usage of release environments for manual validation Measure adoption of the extension of the maintenance policy Broadcast from ELT / senior managers to engineering managers
18.5	Full rollout extension of the maintenance policy to GitLab customers	Socialize the new GitLab maintenance policy to GitLab customers	Measure adoption of the extension of the maintenance policy Blog post for GitLab customers Internal presentation for CSMs

New monthly release process

Release	Item	Description	Key results
18.4	Gather input on the targeted release to establish a new monthly schedule	Coordinate with ELT on the new monthly release workflow	Selection of the targeted release Engineering leadership approval on the targeted release Setup GitLab internal training and announcements Establish metrics of success Update documentation and runbooks
18.5 (tentative) (or the targeted release)	Establish the new monthly release schedule	Introduce the new monthly release workflow. With 18.5, the stable branch will be cut on October 8th, features deployed to GitLab.com after that date won't be included on 18.5	18.5 (pending approval) as the first release with the new monthly schedule Measure the success of the new monthly schedule Rollout LevelUp training to create awareness across Engineering and Product Socialize this change on Engineering all-hands and Infrastructure Platform all-hands Rollout Internal announcement Perform an AMA session

To do

• Coordinate with Delivery PM and Delivery Engineering Manager about the plan