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

Ensure omnibus-gitlab is ready to build packages by asking the Omnibus maintainers
Follow the Creating RC1 guide:
- Update the "Installation from Source" guide => https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9823
- Create the "Update" guides => https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9823 https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1394
- Update the gitignore and license templates => https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9824
- Update the dependencies license list => https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9826
- Ensure above steps are merged to master and marked Pick into Stable for milestone 9.0
- 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.
- Merge CE 9-0-stable into EE 9-0-stable-ee following the Merging a CE stable branch into its EE counterpart guide
- Ensure tests are green on CE
- Ensure tests are green on EE
- Build omnibus packages using buildfrombranch feature: https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master/doc/build#building-a-package-from-a-custom-branch
- Do a manual install on staging.gitlab.com of the custom EE package
- Have the team test staging for massive defects: In #development:
```
```
  @channel
  
  A custom package of `9-0-stable-ee` has been deployed to staging.gitlab.com.
  Please take a few minutes check to ensure it is working as expected before we tag RC1
```
```
- Test a rollback, with restore from the upgrade backup, with the custom package. Ask for assistance in #build if someone there can test it quicker.
- In #releases: I'm going to tag 9.0.0-rc1
- Tag the 9.0.0-rc1 version using the release task:
```
```sh
  bundle exec rake "release[9.0.0-rc1]"
```
```
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-rc1 to staging
Deploy 9.0.0-rc1 to staging.gitlab.com sh # In the chef-repo project: bundle exec rake "deploy:staging[9.0.0-rc1.ee.0, gitlab/unstable]"
In #infrastructure: I'm going to deploy 9.0.0-rc1 to production

Deploy 9.0.0-rc1 to GitLab.com

```sh
# In the chef-repo project:
bundle exec rake "deploy:production[9.0.0-rc1.ee.0, gitlab/unstable]"
```

Create the regression issue in the CE issue tracker using the regression_issue task and bookmark it:
```
```sh
bundle exec rake "regression_issue[9.0.0]"
```
```

Tweet about the 9.0.0-rc1 release:

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

Prepare the blog post using the new_release_post task, in the www-gitlab-com project:
```
```sh
bundle exec rake "new_release_post[9.0]"
```
```

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:
- 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-rc1-ee..9-0-stable-ee -- db/migrate =>
- 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-rc2
- 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
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

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-rc3:
- 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-rc2-ee..9-0-stable-ee -- db/migrate =>
- 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-rc3
- Tag the 9.0.0-rc3 version using the release task:
```
```sh
  bundle exec rake "release[9.0.0-rc3]"
```
```
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-rc3 to staging sh # In the chef-repo project: bundle exec rake "deploy:staging[9.0.0-rc3.ee.0, gitlab/unstable]"
Deploy 9.0.0-rc3 to staging.gitlab.com
In #infrastructure: I'm going to deploy 9.0.0-rc3 to production sh # In the chef-repo project: bundle exec rake "deploy:production[9.0.0-rc3.ee.0, gitlab/unstable]"
Deploy 9.0.0-rc3 to GitLab.com
Flip redirect_http https://gitlab.com/gitlab-com/infrastructure/issues/1358

Tweet about the 9.0.0-rc3 release:

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

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

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-rc7:
- 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-rc6-ee..9-0-stable-ee -- db/migrate => https://gitlab.com/gitlab-org/gitlab-ce/snippets/1655375
- 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-rc7
- Tag the 9.0.0-rc7 version using the release task:
```
```sh
  bundle exec rake "release[9.0.0-rc7]"
```
```
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-rc7 to staging sh # In the chef-repo project: bundle exec rake "deploy:staging[9.0.0-rc7.ee.0, gitlab/unstable]"
Deploy 9.0.0-rc7 to staging.gitlab.com
In #infrastructure: I'm going to deploy 9.0.0-rc7 to production sh # In the chef-repo project: bundle exec rake "deploy:production[9.0.0-rc7.ee.0, gitlab/unstable]"
Deploy 9.0.0-rc7 to GitLab.com

Tweet about the 9.0.0-rc7 release:

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

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:

After feature freeze only regression and security fixes can be cherry-picked into 9-0-stable.
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.

Before 06:00 Pacific (mostly 15:00 CET):
- 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
- Tag the 9.0.0 version using the release task:
```
```sh
  bundle exec rake "release[9.0.0]"
```
```
- Check that EE packages are built, CE packages are built and appears on packages.gitlab.com: EE / CE
Before 07:00 Pacific (mostly 16:00 CET):
- In #infrastructure: I'm going to deploy 9.0.0 to staging
- Deploy 9.0.0 to staging.gitlab.com
- In #infrastructure: I'm going to deploy 9.0.0 to production
- Deploy 9.0.0 to GitLab.com
- Create the 9.0.0 version on https://version.gitlab.com
- Create the first patch issue using the patch_issue task:
```
bundle exec rake "patch_issue[9.0.1]"
```
At 0800 Pacific (mostly 17:00 CET):
- Publish the release blog post
- Ensure someone tweets about the 9.0.0 release

Admin message

Admin message

Release 9.0

First working day after 7th

RC1

RC2

RC3

RC4

RC5

RC6

RC7

QA

Anytime after RC1 but before 22nd

22nd before 1700 CET: