Release 9.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.

  • In #development:

    ```
    @channel
    
    I am about to create the `9-0-stable` branch. Everything merged into `master`
    after this point will go into the next release. Only regression and security fixes
    will be cherry-picked into `9-0-stable`.
    
    Please ensure that merge requests have the correct milestone (`9.0` for this release)
    and the `Pick into Stable` label.
    
    From now on, please follow the "Changes for stable release" process:
    https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#changes-for-stable-releases
    ```
  • Create branch 9-0-stable from master

  • Create branch 9-0-stable-ee from EE master

  • In omnibus create both 9-0-stable and 9-0-stable-ee from master

  • Merge GitLab CE into EE on the stable branches

  • Sync CE, EE, and Omnibus to dev

RC1

RC2

  • Cherry-pick merge requests labeled Pick into Stable for the current milestone (you can take advantage of the Pick into Stable 9.0 merged merge requests page) into the CE 9-0-stable and EE 9-0-stable-ee branches, respectively.

  • Follow the Creating subsequent RCs guide for 9.0.0-rc2:

  • Check that EE packages are built, CE packages are built and appears on packages.gitlab.com: EE & CE

  • In #infrastructure: I'm going to deploy 9.0.0-rc2 to staging sh # In the chef-repo project: bundle exec rake "deploy:staging[9.0.0-rc2.ee.0, gitlab/unstable]"

  • Deploy 9.0.0-rc2 to staging.gitlab.com

  • In #infrastructure: I'm going to deploy 9.0.0-rc2 to production sh # In the chef-repo project: bundle exec rake "deploy:production[9.0.0-rc2.ee.0, gitlab/unstable]"

  • Deploy 9.0.0-rc2 to GitLab.com

  • Tweet about the 9.0.0-rc2 release:

    ```
    GitLab 9.0.0-rc2 is available: https://packages.gitlab.com/gitlab/unstable
    Use at your own risk. Please link regressions issues from
    LINK_TO_REGRESSION_ISSUE

RC3

RC4

  • Cherry-pick merge requests labeled Pick into Stable for the current milestone (you can take advantage of the Pick into Stable 9.0 merged merge requests page) into the CE 9-0-stable and EE 9-0-stable-ee branches, respectively.

  • Follow the Creating subsequent RCs guide for 9.0.0-rc4:

    • Merge CE 9-0-stable into EE 9-0-stable-ee following the Merging a CE stable branch into its EE counterpart guide

    • Check for any problematic migrations in EE (EE migrations include CE ones), and paste the diff in a snippet: git diff v9.0.0-rc3-ee..9-0-stable-ee -- db/migrate =>
      No migrations

    • Sync CE, EE, and Omnibus to dev

    • Ensure tests are green on CE

    • Ensure tests are green on EE

    • In #releases: I'm going to tag 9.0.0-rc4

    • Tag the 9.0.0-rc4 version using the release task:

      ```sh
      bundle exec rake "release[9.0.0-rc4]"
      ```
  • Check that EE packages are built, CE packages are built and appears on packages.gitlab.com: EE & CE

  • In #infrastructure: I'm going to deploy 9.0.0-rc4 to staging sh # In the chef-repo project: bundle exec rake "deploy:staging[9.0.0-rc4.ee.0, gitlab/unstable]"

  • Deploy 9.0.0-rc4 to staging.gitlab.com

  • In #infrastructure: I'm going to deploy 9.0.0-rc4 to production sh # In the chef-repo project: bundle exec rake "deploy:production[9.0.0-rc4.ee.0, gitlab/unstable]"

  • Deploy 9.0.0-rc4 to GitLab.com

  • Tweet about the 9.0.0-rc4 release:

    ```
    GitLab 9.0.0-rc4 is available: https://packages.gitlab.com/gitlab/unstable
    Use at your own risk. Please link regressions issues from
    LINK_TO_REGRESSION_ISSUE
    ```

RC5

  • Cherry-pick merge requests labeled Pick into Stable for the current milestone (you can take advantage of the Pick into Stable 9.0 merged merge requests page) into the CE 9-0-stable and EE 9-0-stable-ee branches, respectively.

  • Follow the Creating subsequent RCs guide for 9.0.0-rc5:

    • Merge CE 9-0-stable into EE 9-0-stable-ee following the Merging a CE stable branch into its EE counterpart guide

    • Check for any problematic migrations in EE (EE migrations include CE ones), and paste the diff in a snippet: git diff v9.0.0-rc4-ee..9-0-stable-ee -- db/migrate =>
      No migrations

    • Sync CE, EE, and Omnibus to dev

    • Ensure tests are green on CE

    • Ensure tests are green on EE

    • In #releases: I'm going to tag 9.0.0-rc5

    • Tag the 9.0.0-rc5 version using the release task:

      ```sh
      bundle exec rake "release[9.0.0-rc5]"
      ```
  • Check that EE packages are built, CE packages are built and appears on packages.gitlab.com: EE & CE

  • In #infrastructure: I'm going to deploy 9.0.0-rc5 to staging sh # In the chef-repo project: bundle exec rake "deploy:staging[9.0.0-rc5.ee.0, gitlab/unstable]"

  • Deploy 9.0.0-rc5 to staging.gitlab.com

  • In #infrastructure: I'm going to deploy 9.0.0-rc5 to production sh # In the chef-repo project: bundle exec rake "deploy:production[9.0.0-rc5.ee.0, gitlab/unstable]"

  • Deploy 9.0.0-rc5 to GitLab.com

  • Tweet about the `9.0.0-rc5 release:

    ```
    GitLab 9.0.0-rc5 is available: https://packages.gitlab.com/gitlab/unstable
    Use at your own risk. Please link regressions issues from
    LINK_TO_REGRESSION_ISSUE
    ```

RC6

  • Cherry-pick merge requests labeled Pick into Stable for the current milestone (you can take advantage of the Pick into Stable 9.0 merged merge requests page) into the CE 9-0-stable and EE 9-0-stable-ee branches, respectively.

  • Follow the Creating subsequent RCs guide for 9.0.0-rc6:

    • Merge CE 9-0-stable into EE 9-0-stable-ee following the Merging a CE stable branch into its EE counterpart guide

    • Check for any problematic migrations in EE (EE migrations include CE ones), and paste the diff in a snippet: git diff v9.0.0-rc5-ee..9-0-stable-ee -- db/migrate =>
      No migrations

    • Sync CE, EE, and Omnibus to dev

    • Ensure tests are green on CE

    • Ensure tests are green on EE

    • In #releases: I'm going to tag 9.0.0-rc6

    • Tag the 9.0.0-rc6 version using the release task:

      ```sh
      bundle exec rake "release[9.0.0-rc6]"
      ```
  • Check that EE packages are built, CE packages are built and appears on packages.gitlab.com: EE & CE

  • In #infrastructure: I'm going to deploy 9.0.0-rc6 to staging sh # In the chef-repo project: bundle exec rake "deploy:staging[9.0.0-rc6.ee.0, gitlab/unstable]"

  • Deploy 9.0.0-rc6 to staging.gitlab.com

  • In #infrastructure: I'm going to deploy 9.0.0-rc6 to production sh # In the chef-repo project: bundle exec rake "deploy:production[9.0.0-rc6.ee.0, gitlab/unstable]"

  • Deploy 9.0.0-rc6 to GitLab.com

  • Tweet about the `9.0.0-rc6 release:

    ```
    GitLab 9.0.0-rc6 is available: https://packages.gitlab.com/gitlab/unstable
    Use at your own risk. Please link regressions issues from
    LINK_TO_REGRESSION_ISSUE
    ```

RC7

QA

  • Determine QA person and notify this person: MENTION_THIS_PERSON_HERE
  • Do QA and fix anything coming out of it: LINK_TO_QA_ISSUE

Anytime after RC1 but before 22nd

  • Check that everyone is mentioned on the blog post using @all:

    ```
    Hello @all, this is the monthly release post that will go out on the 22nd,
    announcing the new GitLab version. Look through it to see if we can make any
    changes and feel free to comment with suggestions or questions!
    ```
    
    or, if the blog post is still very much a work in progress:
    
    ```
    Hello @all, this is the merge request for the monthly release post that will
    go out on the 22nd, announcing the new GitLab version. Right now it's all
    boilerplate, but feel free to remind us about things that shouldn't be left
    out!
    ```
  • Ask in #core for suggestions about who should be this release's MVP. Once chosen, add them to the blog post and to the MVP page, in the same merge request

  • Create another RC as needed.

Keep in mind that:

  1. After feature freeze only regression and security fixes can be cherry-picked into 9-0-stable.
  2. Last RC should point to the same commit as the final release.

Copy-paste the tasks below for any other RCs (be sure to update the RC number).

#### RC2

- [x] Cherry-pick merge requests labeled [`Pick into Stable`] for the current
  milestone (you can take advantage of the
  [`Pick into Stable` 9.0 merged merge requests] page) into
  the CE `9-0-stable` and EE `9-0-stable-ee`
  branches, respectively.
- Follow the [Creating subsequent RCs] guide for `9.0.0-rc2`:
  - [x] Merge CE `9-0-stable` into EE `9-0-stable-ee` following the [Merging a CE stable branch into its EE counterpart] guide
  - [x] Check for any problematic migrations in EE (EE migrations include CE ones), and paste the diff in a snippet: `git diff v9.0.0-rc1-ee..9-0-stable-ee -- db/migrate` =>
  - [x] Sync CE, EE, and Omnibus to `dev`
  - [x] Ensure [tests are green on CE]
  - [ ] Ensure [tests are green on EE]
  - [ ] In `#releases`: I'm going to tag `9.0.0-rc2`
  - [x] Tag the `9.0.0-rc2` version using the [`release` task]:

        ```sh
        bundle exec rake "release[9.0.0-rc2]"
        ```
- [ ] Check that [EE packages are built], [CE packages are built] and appears on `packages.gitlab.com`: [EE & CE](https://packages.gitlab.com/app/gitlab/unstable/search?q=9.0.0-rc2)
- [ ] In `#infrastructure`: I'm going to deploy `9.0.0-rc2` to staging
      ```sh
      # In the chef-repo project:
      bundle exec rake "deploy:staging[9.0.0-rc2.ee.0, gitlab/unstable]"
      ```
- [ ] Deploy [`9.0.0-rc2`](https://packages.gitlab.com/gitlab/unstable/packages/ubuntu/xenial/gitlab-ee_9.0.0-rc2.ee.0_amd64.deb) to [staging.gitlab.com]
- [ ] In `#infrastructure`: I'm going to deploy `9.0.0-rc2` to production
      ```sh
      # In the chef-repo project:
      bundle exec rake "deploy:production[9.0.0-rc2.ee.0, gitlab/unstable]"
      ```
- [ ] Deploy [`9.0.0-rc2`](https://packages.gitlab.com/gitlab/unstable/packages/ubuntu/xenial/gitlab-ee_9.0.0-rc2.ee.0_amd64.deb) to [GitLab.com]
- [x] Tweet about the `9.0.0-rc2` release:

      ```
      GitLab 9.0.0-rc2 is available: https://packages.gitlab.com/gitlab/unstable
      Use at your own risk. Please link regressions issues from
      LINK_TO_REGRESSION_ISSUE
      ```

22nd before 1700 CET:

No new code is added to release that was not included in the last RC. This way we ensure the release does not introduce new regressions.