Merge branch 'monthly-revision' into 'master'

Monthly release doc revision /cc @sytse @jacobvosmaer @marin @dzaporozhets @marc

Merge branch 'monthly-revision' into 'master'
Monthly release doc revision /cc @sytse @jacobvosmaer @marin @dzaporozhets @marc
Sytse Sijbrandij
2 parents 8b9b34f8 6dc09db5
Showing 1 changed file with 111 additions and 50 deletions Show diff stats
doc/release/monthly.md
-# Things to do when creating new monthly minor or major release
-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).
+# Monthly Release
+NOTE: This is a guide for GitLab developers.
-## Install guide up to date?
+# **15th - Code Freeze & Release Manager**
-* References correct GitLab branch `x-x-stable` and correct GitLab shell tag?
+### **1. Stop merging in code, except for important bugfixes**
-## Make upgrade guide
+### **2. Release Manager**
-### From x.x to x.x
+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.
-#### 0. Any major changes? Database updates? Web server change? File structure changes?
+# **18th - Releasing RC1**
+
+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.
+
+### **1. Create an issue for RC1 release**
+
+### **2. Update the installation guide**
+
+1. Check if it references the correct branch `x-x-stable` (doesn't exist yet, but that is okay)
+2. Check the [GitLab Shell version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L782)
+3. Check the [Git version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L794)
+4. There might be other changes. Ask around.
+
+### **3. Create an update guide**
+
+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.
+
+#### 0. Any major changes?
+List any major changes here, so the user is aware of them before starting to upgrade. For instance: 
+- Database updates
+- Web server changes
+- File structure changes
 #### 1. Make backup
@@ -17,9 +38,9 @@ NOTE: This is a guide for GitLab developers. If you are trying to install GitLab
 #### 3. Do users need to update dependencies like `git`?
-- Check the [GitLab Shell version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L782)
+- 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.
-- Check the [Git version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L794)
+- 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.
 #### 4. Get latest code
@@ -29,7 +50,7 @@ NOTE: This is a guide for GitLab developers. If you are trying to install GitLab
 #### 7. Any config files updated since last release?
-Check if any of these changed since last release (~22nd of last month depending on when last release branch was created):
+Check if any of these changed since last release:
 * https://gitlab.com/gitlab-org/gitlab-ce/commits/master/lib/support/nginx/gitlab
 * https://gitlab.com/gitlab-org/gitlab-shell/commits/master/config.yml.example
@@ -40,13 +61,14 @@ Check if any of these changed since last release (~22nd of last month depending 
 #### 8. Need to update init script?
-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
+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
 #### 9. Start application
 #### 10. Check application status
-## Make sure the code quality indicatiors are good
+### **4. Code quality indicatiors**
+Make sure the code quality indicators are green / good.
 * [![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)
@@ -58,49 +80,88 @@ Check if changed since last release (~22nd of last month depending on when last 
 * [![Coverage Status](https://coveralls.io/repos/gitlabhq/gitlabhq/badge.png?branch=master)](https://coveralls.io/r/gitlabhq/gitlabhq)
-## Release Schedule
-
-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:
-
-* 1-7th: Official merge window (see contributing guide).
-* 8-14th: Work on bugfixes, sponsored features and GitLab EE.
-* 15th: Code freeze
-    - Stop merging into master, except essential bugfixes
-    - Select a Release Manager
-* 18th: Release Candidate 1
-    - Set VERSION to x.x.0.rc1
-    - Create annotated tag x.x.0.rc1
-    - Push the changes to GitLab.com, dev.gitlab.com, GitHub
-    - Tweet about the release
-    - Create a new branch on cloud for rc1
-    - Deploy the new branch on Cloud after tests pass
-* 20st: Optional release candidate 2 (x.x.0.rc2, only if rc1 had problems)
-* 22nd: Release
-    - Create x-x-stable branch and push to the repositories
-    - QA
-    - Fix anything coming out of the QA
-    - Set VERSION to x.x.0
-    - Create annotated tag x.x.0
-    - Push VERSION + Tag to master, merge into x-x-stable
-    - Publish blog for new release
-    - Tweet to blog (see below)
-* 22th: release GitLab EE
-* 23nd: optional patch releases (x.x.1, x.x.2, etc., only if there are serious problems)
-* 25th: release GitLab CI
-
-# Write a blog post
+### **5. Set VERSION**
+
+Set VERSION tot x.x.0.rc1
+
+
+### **6. Tag**
+
+Create an annotated tag that points to the version change commit.
+```
+git tag -a vx.x.0.rc1 -m 'Version x.x.0.rc1'
+```
+
+### **7. Tweet**
+
+Tweet about the RC release:
+
+> GitLab x.x.x.rc1 is out. This is a release candidate intended for testing only. Please let us know if you find regressions.
+
+### **8. Update Cloud**
+
+Merge the RC1 code into Cloud. Once the build is green, deploy in the morning.
+
+It is important to do this as soon as possible, so we can catch any errors before we release the full version.
-* Mention what GitLab is on the second line: GitLab is open source software to collaborate on code.
-* Select and thank the the Most Valuable Person (MVP) of this release.
-* Add a note if there are security fixes: This release fixes an important security issue and we advise everyone to upgrade as soon as possible.
-# Tweet
+# **22nd - Release CE and EE**
-Send out a tweet to share the good news with the world. For a major/minor release, list the features in short and link to the blog post.
+For GitLab EE, append -ee to the branches and tags.
-For a RC, make sure to explain what a RC is.
+`x-x-stable-ee`
+
+`v.x.x.0-ee`
+
+### **1. Create x-x-stable branch and push to the repositories**
+
+```
+git checkout master
+git pull
+git checkout -b x-x-stable
+git push <remote> x-x-stable
+```
+
+### **2. Build the Omnibus packages**
+[Follow this guide](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/release.md)
+
+### **3. QA**
+Use the omnibus packages to test using [this guide](https://dev.gitlab.org/gitlab/gitlab-ee/blob/master/doc/release/manual_testing.md)
+
+
+### **4. Fix anything coming out of the QA**
+
+### **5. Set VERSION to x.x.0**
+
+### **6. Create annotated tag vx.x.0**
+```
+git tag -a vx.x.0 -m 'Version x.x.0'
+```
+
+### **7. Push VERSION + Tag to master, merge into x-x-stable**
+```
+git push origin master
+```
+
+Next, merge the VERSION into the x-x-stable branch.
+
+### **8. Push to remotes**
+
+For GitLab CE, push to dev, GitLab.com and GitHub.
+
+For GitLab EE, push to the subscribers repo.
+
+NOTE: You might not have the rights to push to master on dev. Ask Dmitriy.
+
+### **9. Publish blog for new release**
+* Mention what GitLab is on the second line: GitLab is open source software to collaborate on code.
+* Select and thank the the Most Valuable Person (MVP) of this release.
+* Add a note if there are security fixes: This release fixes an important security issue and we advise everyone to upgrade as soon as possible.
-A patch release tweet should specify the fixes it brings and link to the corresponding blog post.
+### **10. Tweet to blog**
+Send out a tweet to share the good news with the world. List the features in short and link to the blog post.
+# **23rd - Optional Patch Release**
+# **25th - Release GitLab CI**
1	-# Things to do when creating new monthly minor or major release
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).	1	+# Monthly Release
		2	+NOTE: This is a guide for GitLab developers.
3		3
4	-## Install guide up to date?	4	+# 15th - Code Freeze & Release Manager
5		5
6	-* References correct GitLab branch `x-x-stable` and correct GitLab shell tag?	6	+### 1. Stop merging in code, except for important bugfixes
7		7
8	-## Make upgrade guide	8	+### 2. Release Manager
9		9
10	-### From x.x to x.x	10	+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.
11		11
12	-#### 0. Any major changes? Database updates? Web server change? File structure changes?	12	+# 18th - Releasing RC1
		13	+
		14	+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.
		15	+
		16	+### 1. Create an issue for RC1 release
		17	+
		18	+### 2. Update the installation guide
		19	+
		20	+1. Check if it references the correct branch `x-x-stable` (doesn't exist yet, but that is okay)
		21	+2. Check the [GitLab Shell version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L782)
		22	+3. Check the [Git version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L794)
		23	+4. There might be other changes. Ask around.
		24	+
		25	+### 3. Create an update guide
		26	+
		27	+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.
		28	+
		29	+#### 0. Any major changes?
		30	+List any major changes here, so the user is aware of them before starting to upgrade. For instance:
		31	+- Database updates
		32	+- Web server changes
		33	+- File structure changes
13		34
14	#### 1. Make backup	35	#### 1. Make backup
15		36
	@@ -17,9 +38,9 @@ NOTE: This is a guide for GitLab developers. If you are trying to install GitLab		@@ -17,9 +38,9 @@ NOTE: This is a guide for GitLab developers. If you are trying to install GitLab
17		38
18	#### 3. Do users need to update dependencies like `git`?	39	#### 3. Do users need to update dependencies like `git`?
19		40
20	-- Check the [GitLab Shell version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L782)	41	+- 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		42
22	-- Check the [Git version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L794)	43	+- 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		44
24	#### 4. Get latest code	45	#### 4. Get latest code
25		46
	@@ -29,7 +50,7 @@ NOTE: This is a guide for GitLab developers. If you are trying to install GitLab		@@ -29,7 +50,7 @@ NOTE: This is a guide for GitLab developers. If you are trying to install GitLab
29		50
30	#### 7. Any config files updated since last release?	51	#### 7. Any config files updated since last release?
31		52
32	-Check if any of these changed since last release (~22nd of last month depending on when last release branch was created):	53	+Check if any of these changed since last release:
33		54
34	* https://gitlab.com/gitlab-org/gitlab-ce/commits/master/lib/support/nginx/gitlab	55	* https://gitlab.com/gitlab-org/gitlab-ce/commits/master/lib/support/nginx/gitlab
35	* https://gitlab.com/gitlab-org/gitlab-shell/commits/master/config.yml.example	56	* https://gitlab.com/gitlab-org/gitlab-shell/commits/master/config.yml.example
	@@ -40,13 +61,14 @@ Check if any of these changed since last release (~22nd of last month depending		@@ -40,13 +61,14 @@ Check if any of these changed since last release (~22nd of last month depending
40		61
41	#### 8. Need to update init script?	62	#### 8. Need to update init script?
42		63
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	64	+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		65
45	#### 9. Start application	66	#### 9. Start application
46		67
47	#### 10. Check application status	68	#### 10. Check application status
48		69
49	-## Make sure the code quality indicatiors are good	70	+### 4. Code quality indicatiors
		71	+Make sure the code quality indicators are green / good.
50		72
51	* [![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)	73	* [![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		74
	@@ -58,49 +80,88 @@ Check if changed since last release (~22nd of last month depending on when last		@@ -58,49 +80,88 @@ Check if changed since last release (~22nd of last month depending on when last
58		80
59	* [![Coverage Status](https://coveralls.io/repos/gitlabhq/gitlabhq/badge.png?branch=master)](https://coveralls.io/r/gitlabhq/gitlabhq)	81	* [![Coverage Status](https://coveralls.io/repos/gitlabhq/gitlabhq/badge.png?branch=master)](https://coveralls.io/r/gitlabhq/gitlabhq)
60		82
61	-## Release Schedule
62	-
63	-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	-
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	-* 22th: release GitLab EE
88	-* 23nd: optional patch releases (x.x.1, x.x.2, etc., only if there are serious problems)
89	-* 25th: release GitLab CI
90	-
91	-# Write a blog post	83	+### 5. Set VERSION
		84	+
		85	+Set VERSION tot x.x.0.rc1
		86	+
		87	+
		88	+### 6. Tag
		89	+
		90	+Create an annotated tag that points to the version change commit.
		91	+```
		92	+git tag -a vx.x.0.rc1 -m 'Version x.x.0.rc1'
		93	+```
		94	+
		95	+### 7. Tweet
		96	+
		97	+Tweet about the RC release:
		98	+
		99	+> GitLab x.x.x.rc1 is out. This is a release candidate intended for testing only. Please let us know if you find regressions.
		100	+
		101	+### 8. Update Cloud
		102	+
		103	+Merge the RC1 code into Cloud. Once the build is green, deploy in the morning.
		104	+
		105	+It is important to do this as soon as possible, so we can catch any errors before we release the full version.
92		106
93	-* Mention what GitLab is on the second line: GitLab is open source software to collaborate on code.
94	-* Select and thank the the Most Valuable Person (MVP) of this release.
95	-* Add a note if there are security fixes: This release fixes an important security issue and we advise everyone to upgrade as soon as possible.
96		107
97	-# Tweet	108	+# 22nd - Release CE and EE
98		109
99	-Send out a tweet to share the good news with the world. For a major/minor release, list the features in short and link to the blog post.	110	+For GitLab EE, append -ee to the branches and tags.
100		111
101	-For a RC, make sure to explain what a RC is.	112	+`x-x-stable-ee`
		113	+
		114	+`v.x.x.0-ee`
		115	+
		116	+### 1. Create x-x-stable branch and push to the repositories
		117	+
		118	+```
		119	+git checkout master
		120	+git pull
		121	+git checkout -b x-x-stable
		122	+git push <remote> x-x-stable
		123	+```
		124	+
		125	+### 2. Build the Omnibus packages
		126	+[Follow this guide](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/release.md)
		127	+
		128	+### 3. QA
		129	+Use the omnibus packages to test using [this guide](https://dev.gitlab.org/gitlab/gitlab-ee/blob/master/doc/release/manual_testing.md)
		130	+
		131	+
		132	+### 4. Fix anything coming out of the QA
		133	+
		134	+### 5. Set VERSION to x.x.0
		135	+
		136	+### 6. Create annotated tag vx.x.0
		137	+```
		138	+git tag -a vx.x.0 -m 'Version x.x.0'
		139	+```
		140	+
		141	+### 7. Push VERSION + Tag to master, merge into x-x-stable
		142	+```
		143	+git push origin master
		144	+```
		145	+
		146	+Next, merge the VERSION into the x-x-stable branch.
		147	+
		148	+### 8. Push to remotes
		149	+
		150	+For GitLab CE, push to dev, GitLab.com and GitHub.
		151	+
		152	+For GitLab EE, push to the subscribers repo.
		153	+
		154	+NOTE: You might not have the rights to push to master on dev. Ask Dmitriy.
		155	+
		156	+### 9. Publish blog for new release
		157	+* Mention what GitLab is on the second line: GitLab is open source software to collaborate on code.
		158	+* Select and thank the the Most Valuable Person (MVP) of this release.
		159	+* Add a note if there are security fixes: This release fixes an important security issue and we advise everyone to upgrade as soon as possible.
102		160
103	-A patch release tweet should specify the fixes it brings and link to the corresponding blog post.	161	+### 10. Tweet to blog
104		162
		163	+Send out a tweet to share the good news with the world. List the features in short and link to the blog post.
105		164
		165	+# 23rd - Optional Patch Release
106		166
		167	+# 25th - Release GitLab CI