Release 11.0
First working day after 7th
Stable branch should be created after the 7th. The 7th is the last date to reliably get things in.
-
Create the ~"Pick into 11.0" group label if it doesn't exist: https://gitlab.com/groups/gitlab-org/labels/new - Title:
Pick into 11.0
- Description:
Merge requests to cherry-pick into the `11-0-stable` branch.
- Color:
#00c8ca
- Title:
-
Make sure the latest CE to EE on master
branches is merged (it will reduce conflicts in the future). Ask in#ce-to-ee
when in doubt. -
Create branch 11-0-stable
from CEmaster
manually -
Create branch 11-0-stable-ee
from EEmaster
manually -
In Omnibus create both 11-0-stable
and11-0-stable-ee
frommaster
manually -
Merge GitLab CE into EE on stable branches following the Merging a CE stable branch into its EE counterpart guide => https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/5936 -
Sync stable branches: CE, EE, and Omnibus to dev
, CE and Omnibus togithub
-
Sync master branches to dev
andgithub
, as the CHANGELOG will be automatically updated on master during tagging
RC1
- Follow the Creating RC1 guide:
-
Create an MR on CE master updating the "Installation from Source" guide, creating the "Update" guides => https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19320 -
Create an MR on EE master creating the "CE to EE" guides => https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/5937 -
Create an MR on CE master updating the .gitignore
,.gitlab-ci.yml
, andDockerfile
templates => https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19573 -
Create an MR on CE master updating the dependencies license list => gitlab-org/gitlab-ce!19574 -
Ensure the above MRs are merged and marked ~"Pick into 11.0" -
Create a task list for RC1: # In the release-tools project: bundle exec rake "patch_issue[11.0.0-rc1]"
-
Subsequent RCs
-
Update the blog post upgrade barometer
section with the migration types for this release, including the time they took to complete. -
Create additional release candidates as needed:
# In the release-tools project (update RC number): bundle exec rake "patch_issue[11.0.0-rc2]"
Keep in mind that:
- After the feature freeze only regression and security fixes should be cherry-picked into stable branches.
- The final RC should point to the same commit as the final release.
Final RC
The final RC should be created on the 21st of the month.
Before 13:00 UTC
Including changes at this stage requires signoff from the VP of Engineering.
-
Create a task list for the final RC: # In the release-tools project (update RC number): bundle exec rake "patch_issue[11.0.0-rc22]"
At 15:00 UTC
If the final RC isn't tagged and deployed by this time, notify the Distribution Lead.
At 20:00 UTC
If the final RC still isn't tagged and deployed by this time, notify the VP of Engineering.
21st
-
At 08:00 UTC, final release is ready for tagging (Including changes at this stage requires signoff from the VP of Engineering):
-
Ensure tests are green on CE stable branch -
Ensure tests are green on EE stable branch -
Ensure tests are green on Omnibus CE stable branch -
Ensure tests are green on Omnibus EE stable branch -
Sync stable branches: CE, EE, and Omnibus to dev
, CE and Omnibus togithub
-
Sync master branches to dev
andgithub
, as the CHANGELOG will be automatically updated on master during tagging
-
-
Before 10:00 UTC:
-
Tag the 11.0.0
version using therelease
task:```sh # In the release-tools project: bundle exec rake "release[11.0.0]" ```
-
Check progress of EE packages build and CE packages build -
Warm up the packages on takeoff by running: sh # In the takeoff project: bin/takeoff-deploy -v 11.0.0-ee.0 -w
-
-
Before 12:00 UTC:
-
Notify #production channel about staging deploy. No need to require confirmation. -
On video call, deploy 11.0.0
to staging.gitlab.com```sh # In the takeoff project: bin/takeoff-deploy -e staging -v 11.0.0-ee.0 ```
-
Notify #production channel about canary deploy. No need to require confirmation. -
On video call, deploy 11.0.0
to canary.gitlab.com```sh # In the takeoff project: bin/takeoff-deploy -e canary -v 11.0.0-ee.0 ```
-
Get confirmation from a production team member to deploy production. Use !oncall prod
if needed to find who's on call. If someone besides the oncall confirms,@mention
the oncall so they are aware. -
On video call, deploy 11.0.0
to GitLab.com```sh # In the takeoff project: bin/takeoff-deploy -e production -v 11.0.0-ee.0 ```
-
No new code can added to the release that was not included in the final RC.
22nd: release day
- At 14:10 UTC:
-
From the build pipeline, manually publish public packages - Make sure that neither packages nor the blog post get published early without approval by the marketing team
-
- At 15:00 UTC:
-
Verify that packages appear on packages.gitlab.com
: EE / CE -
Verify that Docker images appear on hub.docker.com
: EE / CE -
Create the 11.0.0
version on version.gitlab.com -
Ensure someone tweets about the 11.0.0
release in the#releases
channel
-
Exceptions requests
Approved
- #263 (closed) - approved
- #267 (closed) - approved
- #270 (closed) - approved
- #272 (closed) - approved
- #274 (closed) - approved
- #278 (closed) - approved
- #287 (closed) - approved
- #288 (closed) - approved
- #289 (closed) - approved
Not approved
- #275 (closed) - not approved
- #261 (closed) - not approved
- #293 (closed) - not approved
Pending