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

• 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 CE master manually

• Create branch 11-0-stable-ee from EE master manually

• In Omnibus create both 11-0-stable and 11-0-stable-ee from master 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 to github

• Sync master branches to dev and github, 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, and Dockerfile 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:

1. After the feature freeze only regression and security fixes should be cherry-picked into stable branches.
2. 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 to github
  • Sync master branches to dev and github, as the CHANGELOG will be automatically updated on master during tagging

• Before 10:00 UTC:

  • Tag the 11.0.0 version using the release 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

1. #263 (closed) - approved
2. #267 (closed) - approved
3. #270 (closed) - approved
4. #272 (closed) - approved
5. #274 (closed) - approved
6. #278 (closed) - approved
7. #287 (closed) - approved
8. #288 (closed) - approved
9. #289 (closed) - approved

Not approved

1. #275 (closed) - not approved
2. #261 (closed) - not approved
3. #293 (closed) - not approved

Pending

1. #290 (closed)