Commit edc32047dc7f02783134495ce094a29297cca243

Authored by Job van der Voort
1 parent 1feaa336

start to make the monthly release doc a step by step guide

Showing 1 changed file with 81 additions and 36 deletions   Show diff stats
doc/release/monthly.md
1   -# Things to do when creating new monthly minor or major release
  1 +# Monthly Release
2 2 NOTE: This is a guide for GitLab developers. If you are trying to install GitLab see the latest stable [installation guide](install/installation.md) and if you are trying to upgrade, see the [upgrade guides](update).
3 3  
4   -## Install guide up to date?
  4 +# Release Schedule
5 5  
6   -* References correct GitLab branch `x-x-stable` and correct GitLab shell tag?
  6 +After making the release branch new commits are cherry-picked from master. When the release gets closer we get more selective what is cherry-picked. The days of the month are approximately as follows:
  7 +
  8 +* 1-7th: Official merge window (see contributing guide).
  9 +* 8-14th: Work on bugfixes, sponsored features and GitLab EE.
  10 +* 15th: Code freeze
  11 +* 18th: Release Candidate 1
  12 +* 20st: Optional release candidate 2
  13 +* 22nd: Release
  14 +* 23nd: Optional patch releases
  15 +* 24-end of month: Release GitLab EE and GitLab CI
  16 +
  17 +# 15th - Code Freeze & Release Manager
  18 +
  19 +- Stop merging in code, except for important bugfixes
  20 +
  21 +## Release Manager
  22 +
  23 +A release manager is selected that coordinates the entire release of this version. The release manager has to make sure all the steps below are done and delegated where necessary. This person should also make sure this document is kept up to date and issues are created and updated.
  24 +
  25 +# 18th - Releasing RC1
  26 +
  27 +> Yo dawg, I heard you like releases..
  28 +
  29 +The RC1 release comes with the task to update the installation and upgrade docs. Be mindful that there might already be merge requests for this on GitLab or GitHub.
  30 +
  31 +### 1. Create an issue for RC1 release
  32 +
  33 +### 2. Update the installation guide
  34 +
  35 +1. Check if it references the correct branch `x-x-stable` (doesn't exist yet, but that is okay)
  36 +2. Check the [GitLab Shell version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L782)
  37 +3. Check the [Git version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L794)
  38 +4. There might be other changes. Ask around.
7 39  
8   -## Make upgrade guide
  40 +### 3. Create an update guide
9 41  
10   -### From x.x to x.x
  42 +It's best to copy paste the previous guide and make changes where necessary. The typical steps are listed below with any points you should specifically look at.
11 43  
12   -#### 0. Any major changes? Database updates? Web server change? File structure changes?
  44 +#### 0. Any major changes?
  45 +List any major changes here, so the user is aware of them before starting to upgrade. For instance:
  46 +- Database updates
  47 +- Web server changes
  48 +- File structure changes
13 49  
14 50 #### 1. Make backup
15 51  
... ... @@ -17,9 +53,9 @@ NOTE: This is a guide for GitLab developers. If you are trying to install GitLab
17 53  
18 54 #### 3. Do users need to update dependencies like `git`?
19 55  
20   -- Check the [GitLab Shell version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L782)
  56 +- Check if the [GitLab Shell version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L782) changed since the last release.
21 57  
22   -- Check the [Git version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L794)
  58 +- Check if the [Git version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L794) changed since the last release.
23 59  
24 60 #### 4. Get latest code
25 61  
... ... @@ -29,7 +65,7 @@ NOTE: This is a guide for GitLab developers. If you are trying to install GitLab
29 65  
30 66 #### 7. Any config files updated since last release?
31 67  
32   -Check if any of these changed since last release (~22nd of last month depending on when last release branch was created):
  68 +Check if any of these changed since last release:
33 69  
34 70 * https://gitlab.com/gitlab-org/gitlab-ce/commits/master/lib/support/nginx/gitlab
35 71 * https://gitlab.com/gitlab-org/gitlab-shell/commits/master/config.yml.example
... ... @@ -40,13 +76,14 @@ Check if any of these changed since last release (~22nd of last month depending
40 76  
41 77 #### 8. Need to update init script?
42 78  
43   -Check if changed since last release (~22nd of last month depending on when last release branch was created): https://gitlab.com/gitlab-org/gitlab-ce/commits/master/lib/support/init.d/gitlab
  79 +Check if the init.d/gitlab script changed since last release: https://gitlab.com/gitlab-org/gitlab-ce/commits/master/lib/support/init.d/gitlab
44 80  
45 81 #### 9. Start application
46 82  
47 83 #### 10. Check application status
48 84  
49   -## Make sure the code quality indicatiors are good
  85 +### 4. Code quality indicatiors
  86 +Make sure the code quality indicators are green / good.
50 87  
51 88 * [![build status](http://ci.gitlab.org/projects/1/status.png?ref=master)](http://ci.gitlab.org/projects/1?ref=master) on ci.gitlab.org (master branch)
52 89  
... ... @@ -58,34 +95,42 @@ Check if changed since last release (~22nd of last month depending on when last
58 95  
59 96 * [![Coverage Status](https://coveralls.io/repos/gitlabhq/gitlabhq/badge.png?branch=master)](https://coveralls.io/r/gitlabhq/gitlabhq)
60 97  
61   -## Release Schedule
  98 +### 5. Set VERSION
  99 +
  100 +Set VERSION tot x.x.0.rc1
  101 +
  102 +
  103 +### 6. Tag
  104 +
  105 +Create an annotated tag that points to the version change commit.
  106 +```
  107 +git tag -a vx.x.0.rc1 -m 'Version x.x.0.rc1'
  108 +```
  109 +
  110 +### 7. Tweet
  111 +
  112 +Tweet about the RC release. Make sure to explain what a RC is.
  113 +
  114 +### 8. Update Cloud
  115 +
  116 +Merge the RC1 code into Cloud. Once the build is green, deploy in the morning.
  117 +
  118 +It is important to do this as soon as possible, so we can catch any errors before we release the full version.
  119 +
  120 +
  121 +# 22nd - Release
62 122  
63 123 After making the release branch new commits are cherry-picked from master. When the release gets closer we get more selective what is cherry-picked. The days of the month are approximately as follows:
64 124  
65   -* 1-7th: Official merge window (see contributing guide).
66   -* 8-14th: Work on bugfixes, sponsored features and GitLab EE.
67   -* 15th: Code freeze
68   - - Stop merging into master, except essential bugfixes
69   - - Select a Release Manager
70   -* 18th: Release Candidate 1
71   - - Set VERSION to x.x.0.rc1
72   - - Create annotated tag x.x.0.rc1
73   - - Push the changes to GitLab.com, dev.gitlab.com, GitHub
74   - - Tweet about the release
75   - - Create a new branch on cloud for rc1
76   - - Deploy the new branch on Cloud after tests pass
77   -* 20st: Optional release candidate 2 (x.x.0.rc2, only if rc1 had problems)
78   -* 22nd: Release
79   - - Create x-x-stable branch and push to the repositories
80   - - QA
81   - - Fix anything coming out of the QA
82   - - Set VERSION to x.x.0
83   - - Create annotated tag x.x.0
84   - - Push VERSION + Tag to master, merge into x-x-stable
85   - - Publish blog for new release
86   - - Tweet to blog (see below)
87   -* 23nd: optional patch releases (x.x.1, x.x.2, etc., only if there are serious problems)
88   -* 24-end of month: release GitLab EE and GitLab CI
  125 +
  126 +- Create x-x-stable branch and push to the repositories
  127 +- QA
  128 +- Fix anything coming out of the QA
  129 +- Set VERSION to x.x.0
  130 +- Create annotated tag x.x.0
  131 +- Push VERSION + Tag to master, merge into x-x-stable
  132 +- Publish blog for new release
  133 +- Tweet to blog (see below)
89 134  
90 135 # Write a blog post
91 136  
... ...