16.0 Release Preparation - What to expect
What to expect?
16.0 release preparation will begin earlier than normal to give release managers extra time to handle the additional work that we expect will come from merging lots of breaking changes. As always we're working to provide a safe 16.0 release for our users on the 22nd.
We'll be identifying the guaranteed sha
for release on 2023-05-11. This is a few working days earlier than most releases. We decided on this date first because we want an extra day or two to decrease risk, and second because the 22nd falls on a Monday, so most of the release preparation is pushed a few days earlier due to the 20th and 21st falling on a weekend. This means that in the event of incidents or other issues affecting stability we may make the 16.0 release from the sha
chosen on 11th.
If you have a change that must make 16.0 we recommend merging it in as soon as you can to be sure of making the release cut.
In the days between Thursday 2023-05-11 and Wednesday 2023-05-17 we will try to deploy as often as we can. Packages that are deployed to production and look stable may be included in 16.0, though this cannot be guaranteed.
We need your help
If you find something that has been merged when it shouldn't have been or spot a bug please alert the release managers in the #releases
channel and mention @release-managers
.
Want to keep up with the release steps?
We'll be announcing the guaranteed sha
, the candidate commit, stable branch creation, and the final commit for release in #releases, #development, #backend, #frontend and #quality Slack channels. You can also follow the steps in the release issue.
Detailed summary of dates
These dates are subject to the availability of gitlab.com. In case of incidents or poor availability, the plan might change. To guarantee that an MR is included in 16.0, merge it before 11th May.
- 11th - We will identify the first guaranteed commit
sha
- 12th - We will identify a candidate commit
sha
(this is usually different than the first sha, but if there is any instability or incidents, it may be the same) - 13th - 14th - Weekend
- 15th - 17th - Continue to identify and announce more recent stable commits to be included in the release
- 17th - Release managers will decide on the final stable deployment that will be used for the release candidate
- 18th - The release candidate will be tagged and announced
- 19th - The 16.0 release will be tagged
- 20th - 21st - Weekend
- 22nd - The 16.0 release will be published
If you have questions
Please feel free to ask process-related questions on this issue. For anything related to a specific MR or deployment please use the #releases
Slack channel and ping @release-managers
16.0
Guidelines for merging changes into- Over-communicate breaking changes ahead of time. It's not too early to start, especially if a change requires active actions from our users.
- Don't merge breaking changes that require communication before they are ready to be go live. You can assume that a merged change will be on GitLab.com in approximately 12 hours. If release managers have to block a package and revert something this will delay everyone's work by half a day. Half a day closer to the 22nd could make the difference between making it into 16.0 or not.
- Use feature flags if you want to control timing, but don't forget that it has to be removed, or defaulted to
true
in time for the release - When changing a feature flag, run the command from the
#production
channel to ensure maximum visibility - When merging an MR or changing a feature flag, the DRI for that change should also monitor afterwards to ensure it is operating as intended
- Keep the support department in the loop, they will have more tickets due to breaking changes
- Never assume dates in communications, we cannot ensure that a specific change will make it to GitLab.com on a specific day
Guidelines for adding a last minute breaking change
If you need to add a breaking change during the 16.0 development cycle:
- Communicate with your product manager to ensure the breaking change is expected and has been properly communicated to GitLab users.
- Add it to this spreadsheet
- Inform Release Managers (
@release-managers
) in the#releases
channel in Slack. - Get it merged as early in the milestone, by the 11th if you can.