Release 10.2.3
-
Schedule the patch release by setting a Due date -
Create preparation MRs by following the instructions in release-tools. -
Cherry-pick changes into preparation MRs following their instructions -
Cherry-pick remaining merge requests labeled ~"Pick into 10.2" using this Merged MRs list -
Check the following list of critical issues/MRs which are to be included in 10.2.3
. Where appropriate, ensure each has made it into both CE and EE -
Make sure the Due date is up-to-date -
Merge CE 10-2-stable
into EE10-2-stable-ee
following the Merging a CE stable branch into its EE counterpart guide -
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 -
If needed, sync tags for dependencies ( gitlab-shell
,gitlab-workhorse
,gitlab-pages
,gitaly
) todev
andgithub
(when applicable. Builds should fail if this is needed.) -
Check for any problematic migrations in EE (EE migrations include CE ones), and paste the diff in a snippet: git diff v10.2.2-ee..10-2-stable-ee -- db/migrate db/post_migrate
=> https://gitlab.com/gitlab-org/gitlab-ce/snippets/1686918 -
While waiting for tests to be green, now is a good time to create the blog post MR. Look at previous MRs for examples. => BLOG_POST_MR -
Ensure builds are green on CE stable branch and EE stable branch -
Ensure builds are green on Omnibus CE stable branch and Omnibus EE stable branch -
In #releases
: I'm going to tag10.2.3
-
Tag the 10.2.3
version using therelease
task:```sh # In the release-tools project: bundle exec rake "release[10.2.3]" ```
-
Check progress of EE packages build and CE packages build -
In #production
: I'm going to deploy10.2.3
to staging -
Get confirmation from a production team member. Use !oncall prod
if needed to find who's on call. -
On video call, deploy release 10.2.3
to staging.gitlab.comsh # In the takeoff project: bundle exec rake "deploy[staging, 10.2.3-ee.0]"
-
In #production
: I'm going to deploy10.2.3
to canary -
Get confirmation from a production team member. Use !oncall prod
if needed to find who's on call. -
On video call, deploy release 10.2.3
to canary.gitlab.comsh # In the takeoff project: bundle exec rake "deploy[canary, 10.2.3-ee.0]"
-
In #production
: I'm going to deploy10.2.3
to production -
Get confirmation from a production team member. Use !oncall prod
if needed to find who's on call. -
Publicly [announce the deployment] on Twitter and with the GitLab.com deploy alert banner in the #production
channel * With downtime: 1 hour before!tweet "We will be deploying GitLab EE 10.2.3 starting at X:Y UTC, 15 mins of downtime expected" !broadcast --start X:Y --end A:B "We are currently deploying GitLab EE 10.2.3. For status updates during the downtime, please follow [@gitlabstatus](https://twitter.com/gitlabstatus)"
* Without downtime: 15 minutes before!tweet "We are about to deploy GitLab EE 10.2.3 starting at X:Y UTC" !broadcast --start X:Y --end A:B "We are currently deploying GitLab EE 10.2.3"
-
On video call, deploy release 10.2.3
to GitLab.comsh # In the takeoff project: bundle exec rake "deploy[production, 10.2.3-ee.0]"
-
Create the 10.2.3
version on https://version.gitlab.com: https://version.gitlab.com/versions/294 -
Deploy the blog post -
Tweet (prepare the Tweet text below or paste the tweet URL instead): ``` GitLab 10.2.3 is released! BLOG_POST_URL DESCRIPTION OF THE CHANGES ```
-
Add omnibus-gitlab/10.2.3+ce.0
CHANGELOG.md items toomnibus-gitlab/master
CHANGELOG.md
For references: