From 07cca8cc0c5bd6913e55c99a0493dc2f92dcdbb5 Mon Sep 17 00:00:00 2001 From: Dmitriy Zaporozhets Date: Tue, 11 Nov 2014 11:47:44 +0200 Subject: Use release tool for monthly releases Signed-off-by: Dmitriy Zaporozhets --- doc/release/monthly.md | 84 +++++++++++++------------------------------------- 1 file changed, 22 insertions(+), 62 deletions(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 386c19c0fe0..7354efc3e2e 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -143,35 +143,19 @@ Make sure the code quality indicators are green / good. - [![Coverage Status](https://coveralls.io/repos/gitlabhq/gitlabhq/badge.png?branch=master)](https://coveralls.io/r/gitlabhq/gitlabhq) -### **4. Set VERSION** +### **4. Run release tool** -Change version in VERSION to `x.x.0.rc1`. - -### **5. Tag** - -Create an annotated tag that points to the version change commit: +Get release tools ``` -git tag -a vx.x.0.rc1 -m 'Version x.x.0.rc1' +git clone git@dev.gitlab.org:gitlab/release-tools.git +cd release-tools ``` -Tags should be created for both GitLab CE and GitLab EE. Don't forget to push tags to all remotes. - -``` -git push remote_name vx.x.0.rc1 -``` - -### **6. Create stable branches** - -For GitLab EE, append `-ee` to the branch. - -`x-x-stable-ee` +Create release candidate and stable branch: ``` -git checkout master -git pull -git checkout -b x-x-stable -git push x-x-stable +bundle exec rake release["x.x.0.rc1"] ``` Now developers can use master for merging new features. @@ -245,69 +229,45 @@ create an issue about it in order to discuss the next steps after the release. # **22nd - Release CE and EE** -For GitLab EE, append `-ee` to the branches and tags. - -`x-x-stable-ee` - -`v.x.x.0-ee` - -Note: Merge CE into EE if needed. +**Make sure EE `x-x-stable-ee` has latest changes from CE `x-x-stable`** -### **1. Set VERSION to x.x.x and push** -- Change the GITLAB_SHELL_VERSION file in `master` of the CE repository if the version changed. -- Change the GITLAB_SHELL_VERSION file in `master` of the EE repository if the version changed. -- Change the VERSION file in `master` branch of the CE repository and commit and push to origin. -- Change the VERSION file in `master` branch of the EE repository and commit and push to origin. +### **1. Release code** -### **2. Update installation.md** - -Update [installation.md](/doc/install/installation.md) to the newest version in master. - -### **3. Push latest changes from x-x-stable branch to dev.gitlab.org** +Get release tools ``` -git checkout -b x-x-stable -git push origin x-x-stable +git clone git@dev.gitlab.org:gitlab/release-tools.git +cd release-tools ``` -### **4. Build the Omnibus packages** - -Follow the [release doc in the Omnibus repository](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/release.md). -This can happen before tagging because Omnibus uses tags in its own repo and SHA1's to refer to the GitLab codebase. - -### **5. Create annotated tag vx.x.x** - -In `x-x-stable` branch check for the SHA-1 of the commit with VERSION file changed. Tag that commit, +Bump version, create release tag and push to remotes: ``` -git tag -a vx.x.0 -m 'Version x.x.0' xxxxx +bundle exec rake release["x.x.0"] ``` -where `xxxxx` is SHA-1. -### **6. Push the tag and x-x-stable branch to the remotes** +### **2. Update installation.md** -For GitLab CE, push to dev, GitLab.com and GitHub. +Update [installation.md](/doc/install/installation.md) to the newest version in master. -For GitLab EE, push to the subscribers repo. -Make sure the branch is marked 'protected' on each of the remotes you pushed to. +### **3. Build the Omnibus packages** + +Follow the [release doc in the Omnibus repository](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/release.md). +This can happen before tagging because Omnibus uses tags in its own repo and SHA1's to refer to the GitLab codebase. -``` -git push x-x-stable(-ee) -git push vx.x.0 -``` -### **7. Publish packages for new release** +### **4. Publish packages for new release** Update `downloads/index.html` and `downloads/archive/index.html` in `www-gitlab-com` repository. -### **8. Publish blog for new release** +### **5. Publish blog for new release** Merge the [blog merge request](#1-prepare-the-blog-post) in `www-gitlab-com` repository. -### **9. Tweet to blog** +### **6. Tweet to blog** Send out a tweet to share the good news with the world. List the most important features and link to the blog post. -- cgit v1.2.1 From 1d1b21164258c2e2a6e1d782e517871c33ea961d Mon Sep 17 00:00:00 2001 From: Dmitriy Zaporozhets Date: Tue, 11 Nov 2014 12:01:47 +0200 Subject: Use release tools in patch release Signed-off-by: Dmitriy Zaporozhets --- doc/release/patch.md | 31 +++++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-) (limited to 'doc/release') diff --git a/doc/release/patch.md b/doc/release/patch.md index 5d2fa053cac..6ed56427e9a 100644 --- a/doc/release/patch.md +++ b/doc/release/patch.md @@ -10,6 +10,8 @@ Otherwise include it in the monthly release and note there was a regression fix ## Release Procedure +### Preparation + 1. Verify that the issue can be reproduced 1. Note in the 'GitLab X.X regressions' that you will create a patch 1. Create an issue on private GitLab development server @@ -17,12 +19,33 @@ Otherwise include it in the monthly release and note there was a regression fix 1. Fix the issue on a feature branch, do this on the private GitLab development server 1. Consider creating and testing workarounds 1. After the branch is merged into master, cherry pick the commit(s) into the current stable branch +1. Make sure that the build has passed and all tests are passing 1. In a separate commit in the stable branch update the CHANGELOG 1. For EE, update the CHANGELOG-EE if it is EE specific fix. Otherwise, merge the stable CE branch and add to CHANGELOG-EE "Merge community edition changes for version X.X.X" -1. In a separate commit in the stable branch update the VERSION -1. Create an annotated tag vX.X.X for CE and another patch release for EE `git tag -a vx.x.x -m 'Version x.x.x'` -1. Make sure that the build has passed and all tests are passing -1. Push the code and the tags to all the CE and EE repositories + +### Bump version + +Get release tools + +``` +git clone git@dev.gitlab.org:gitlab/release-tools.git +cd release-tools +``` + +Bump version in stable branch, create release tag and push to remotes: + +``` +bundle exec rake release["x.x.x"] +``` + +Or if you need to release only EE: + +``` +CE=false be rake release['x.x.x'] +``` + +### Release + 1. Apply the patch to GitLab Cloud and the private GitLab development server 1. [Build new packages with the latest version](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/release.md) 1. Cherry-pick the changelog update back into master -- cgit v1.2.1 From a15dc7b8141e4aa981409bffd2bb6ad311902dfa Mon Sep 17 00:00:00 2001 From: Dmitriy Zaporozhets Date: Tue, 11 Nov 2014 10:22:05 +0000 Subject: Add tip about EE and CE master synced before release rc1 --- doc/release/monthly.md | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 7354efc3e2e..fa1a883f4b2 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -145,6 +145,8 @@ Make sure the code quality indicators are green / good. ### **4. Run release tool** +**Make sure EE `master` has latest changes from CE `master`** + Get release tools ``` -- cgit v1.2.1 From 116f73b540ba0249e8df1da97fd4189b0327ebce Mon Sep 17 00:00:00 2001 From: Dmitriy Zaporozhets Date: Tue, 11 Nov 2014 18:48:39 +0200 Subject: Sync master branch before releasing rc Signed-off-by: Dmitriy Zaporozhets --- doc/release/monthly.md | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index fa1a883f4b2..affe634587d 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -154,6 +154,13 @@ git clone git@dev.gitlab.org:gitlab/release-tools.git cd release-tools ``` +Release candidate creates stable branch from master. +So we need to sync master branch between all CE remotes. Also do same for EE. + +``` +bundle exec rake sync +``` + Create release candidate and stable branch: ``` -- cgit v1.2.1 From de3bef058ee16aae0f29802e39c3af24c5b79790 Mon Sep 17 00:00:00 2001 From: Jacob Vosmaer Date: Fri, 14 Nov 2014 11:47:08 +0100 Subject: Gitlab.com uses special packages, build them first --- doc/release/monthly.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 386c19c0fe0..e0c98fbce76 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -316,7 +316,8 @@ Proposed tweet for CE "GitLab X.X is released! It brings *** " # **1 workday after release - Update GitLab.com** -Update GitLab.com from RC1 to the released package. +- Build a package for gitlab.com based on the official release instead of RC1 +- Deploy the package # **25th - Release GitLab CI** -- cgit v1.2.1 From f68003560d96a9c2b9496e9091c809d1e17402e9 Mon Sep 17 00:00:00 2001 From: Jacob Vosmaer Date: Fri, 21 Nov 2014 09:59:46 +0100 Subject: The blog post will trigger a mail to the list --- doc/release/security.md | 1 - 1 file changed, 1 deletion(-) (limited to 'doc/release') diff --git a/doc/release/security.md b/doc/release/security.md index 79d23c02ea4..d335407797b 100644 --- a/doc/release/security.md +++ b/doc/release/security.md @@ -18,7 +18,6 @@ Please report suspected security vulnerabilities in private to Date: Sun, 23 Nov 2014 01:11:06 -0800 Subject: update order of upgrade guide GitLab needs to be stopped when backup is took. --- doc/release/monthly.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index c50bfc21f8f..b391d8ca6ab 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -91,9 +91,9 @@ List any major changes here, so the user is aware of them before starting to upg - Web server changes - File structure changes -#### 1. Make backup +#### 1. Stop server -#### 2. Stop server +#### 2. Make backup #### 3. Do users need to update dependencies like `git`? -- cgit v1.2.1 From e0c870c0451789318e46ff5cb2b44a8d7d555f4c Mon Sep 17 00:00:00 2001 From: Jacob Vosmaer Date: Mon, 24 Nov 2014 12:14:07 +0100 Subject: The release manager handles all releases --- doc/release/monthly.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index c50bfc21f8f..e81ee12af6c 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -8,7 +8,9 @@ NOTE: This is a guide for GitLab developers. ### **2. Release Manager** -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. +A release manager is selected that coordinates all releases the coming month. +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. ### **3. Create an overall issue** -- cgit v1.2.1 From 4e3bf439cba782bf7d3ea326f0f6f5878166f0e2 Mon Sep 17 00:00:00 2001 From: Jacob Vosmaer Date: Mon, 24 Nov 2014 12:14:19 +0100 Subject: Establish ownership of security releases --- doc/release/patch.md | 1 + doc/release/security.md | 2 ++ 2 files changed, 3 insertions(+) (limited to 'doc/release') diff --git a/doc/release/patch.md b/doc/release/patch.md index 6ed56427e9a..ce5c2170302 100644 --- a/doc/release/patch.md +++ b/doc/release/patch.md @@ -17,6 +17,7 @@ Otherwise include it in the monthly release and note there was a regression fix 1. Create an issue on private GitLab development server 1. Name the issue "Release X.X.X CE and X.X.X EE", this will make searching easier 1. Fix the issue on a feature branch, do this on the private GitLab development server +1. If it is a security issue, then assign it to the release manager and apply a 'security' label 1. Consider creating and testing workarounds 1. After the branch is merged into master, cherry pick the commit(s) into the current stable branch 1. Make sure that the build has passed and all tests are passing diff --git a/doc/release/security.md b/doc/release/security.md index 79d23c02ea4..a7fb57921df 100644 --- a/doc/release/security.md +++ b/doc/release/security.md @@ -14,7 +14,9 @@ Please report suspected security vulnerabilities in private to Date: Mon, 24 Nov 2014 14:59:54 +0100 Subject: Explicitly mention patch releases --- doc/release/monthly.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index e81ee12af6c..64a8bc98344 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -8,7 +8,7 @@ NOTE: This is a guide for GitLab developers. ### **2. Release Manager** -A release manager is selected that coordinates all releases the coming month. +A release manager is selected that coordinates all releases the coming month, including the patch releases for previous releases. 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. -- cgit v1.2.1 From 106de470c95267dbfef7078839477eb844a11689 Mon Sep 17 00:00:00 2001 From: Jacob Vosmaer Date: Wed, 3 Dec 2014 14:21:00 +0100 Subject: Use clickable checkboxes in issue template --- doc/release/monthly.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 64a8bc98344..4c1dd5af46b 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -20,36 +20,36 @@ Replace the dates with actual dates based on the number of workdays before the r ``` Xth: -* Update the changelog (#LINK) -* Triage the omnibus-gitlab milestone +- [ ] Update the changelog (#LINK) +- [ ] Triage the omnibus-gitlab milestone Xth: -* Merge CE in to EE (#LINK) -* Close the omnibus-gitlab milestone +- [ ] Merge CE in to EE (#LINK) +- [ ] Close the omnibus-gitlab milestone Xth: -* Create x.x.0.rc1 (#LINK) -* Build package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package) +- [ ] Create x.x.0.rc1 (#LINK) +- [ ] Build package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package) Xth: -* Update GitLab.com with rc1 (#LINK) (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#deploy-the-package) -* Regression issue and tweet about rc1 (#LINK) -* Start blog post (#LINK) +- [ ] Update GitLab.com with rc1 (#LINK) (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#deploy-the-package) +- [ ] Regression issue and tweet about rc1 (#LINK) +- [ ] Start blog post (#LINK) Xth: -* Do QA and fix anything coming out of it (#LINK) +- [ ] Do QA and fix anything coming out of it (#LINK) 22nd: -* Release CE and EE (#LINK) +- [ ] Release CE and EE (#LINK) Xth: -* * Deploy to GitLab.com (#LINK) +- [ ] Deploy to GitLab.com (#LINK) ``` -- cgit v1.2.1 From 4ce27042f9db09f80cca071a5d0571e7205441f3 Mon Sep 17 00:00:00 2001 From: Jacob Vosmaer Date: Wed, 3 Dec 2014 14:41:39 +0100 Subject: The second gitlab.com deploy should be easy --- doc/release/monthly.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 4c1dd5af46b..383064b5e6b 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -288,7 +288,7 @@ Proposed tweet for CE "GitLab X.X is released! It brings *** " # **1 workday after release - Update GitLab.com** - Build a package for gitlab.com based on the official release instead of RC1 -- Deploy the package +- Deploy the package (should not need downtime because of the small difference with RC1) # **25th - Release GitLab CI** -- cgit v1.2.1 From a8ce1d88b5f9d85dc78267363bbe5de7f81b1807 Mon Sep 17 00:00:00 2001 From: Jacob Vosmaer Date: Wed, 3 Dec 2014 15:40:12 +0100 Subject: Release CI at the same time as CE and EE --- doc/release/monthly.md | 50 ++++++++++++++++++++++++++++++++++---------------- 1 file changed, 34 insertions(+), 16 deletions(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 383064b5e6b..9b05fea8c8a 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -20,7 +20,9 @@ Replace the dates with actual dates based on the number of workdays before the r ``` Xth: -- [ ] Update the changelog (#LINK) +- [ ] Update the CE changelog (#LINK) +- [ ] Update the EE changelog (#LINK) +- [ ] Update the CI changelog (#LINK) - [ ] Triage the omnibus-gitlab milestone Xth: @@ -31,12 +33,14 @@ Xth: Xth: - [ ] Create x.x.0.rc1 (#LINK) +- [ ] Create x.x.0-ee.rc1 (#LINK) +- [ ] Create CI y.y.0.rc1 (#LINK) - [ ] Build package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package) Xth: - [ ] Update GitLab.com with rc1 (#LINK) (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#deploy-the-package) -- [ ] Regression issue and tweet about rc1 (#LINK) +- [ ] Regression issues (CE, CI) and tweet about rc1 (#LINK) - [ ] Start blog post (#LINK) Xth: @@ -45,7 +49,7 @@ Xth: 22nd: -- [ ] Release CE and EE (#LINK) +- [ ] Release CE, EE and CI (#LINK) Xth: @@ -57,6 +61,8 @@ Xth: Any changes not yet added to the changelog are added by lead developer and in that merge request the complete team is asked if there is anything missing. +There are three changelogs that need to be updated: CE, EE and CI. + ### **5. Take weekend and vacations into account** Ensure that there is enough time to incorporate the findings of the release candidate, etc. @@ -81,6 +87,7 @@ The RC1 release comes with the task to update the installation and upgrade docs. 1. Create: CE update guide from previous version. Like `7.3-to-7.4.md` 1. Create: CE to EE update guide in EE repository for latest version. 1. Update: `6.x-or-7.x-to-7.x.md` to latest version. +1. Create: CI update guide from previous version 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. @@ -173,6 +180,24 @@ Now developers can use master for merging new features. So you should use stable branch for future code chages related to release. +### 5. Release GitLab CI RC1 + +Add to your local `gitlab-ci/.git/config`: + +``` +[remote "public"] + url = none + pushurl = git@dev.gitlab.org:gitlab/gitlab-ci.git + pushurl = git@gitlab.com:gitlab-org/gitlab-ci.git + pushurl = git@github.com:gitlabhq/gitlab-ci.git +``` + +* Create a stable branch `x-y-stable` +* Bump VERSION to `x.y.0.rc1` +* `git tag -a v$(cat VERSION) -m "Version $(cat VERSION)" +* `git push public x-y-stable v$(cat VERSION)` + + # **4 workdays before release - Release RC1** ### **1. Determine QA person @@ -191,6 +216,7 @@ It is important to do this as soon as possible, so we can catch any errors befor - Start with a complete copy of the [release blog template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/release_blog_template.md) and fill it out. - Check the changelog of CE and EE for important changes. +- Also check the CI changelog - Create a WIP MR for the blog post - Ask Dmitriy to add screenshots to the WIP MR. - Decide with team who will be the MVP user. @@ -258,6 +284,11 @@ Bump version, create release tag and push to remotes: bundle exec rake release["x.x.0"] ``` +Also perform these steps for GitLab CI: + +- bump version in the stable branch +- create annotated tag +- push the stable branch and the annotated tag to the public repositories ### **2. Update installation.md** @@ -289,16 +320,3 @@ Proposed tweet for CE "GitLab X.X is released! It brings *** " - Build a package for gitlab.com based on the official release instead of RC1 - Deploy the package (should not need downtime because of the small difference with RC1) - -# **25th - Release GitLab CI** - -- Create the update guid `doc/x.x-to-x.x.md`. -- Update CHANGELOG -- Bump version -- Create annotated tags `git tag -a vx.x.0 -m 'Version x.x.0' xxxxx` -- Create stable branch `x-x-stable` -- Create GitHub release post -- Post to blog about release -- Post to twitter - - -- cgit v1.2.1 From cdabe7302571a21fd377505f144c053b59adb738 Mon Sep 17 00:00:00 2001 From: Jacob Vosmaer Date: Wed, 3 Dec 2014 16:30:57 +0100 Subject: Fix EE RC1 tag name --- doc/release/monthly.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 9b05fea8c8a..a95ba2e107b 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -33,7 +33,7 @@ Xth: Xth: - [ ] Create x.x.0.rc1 (#LINK) -- [ ] Create x.x.0-ee.rc1 (#LINK) +- [ ] Create x.x.0.rc1-ee (#LINK) - [ ] Create CI y.y.0.rc1 (#LINK) - [ ] Build package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package) -- cgit v1.2.1 From 1aca3718807019315fa2e31c1da58183a9e25f5e Mon Sep 17 00:00:00 2001 From: Jacob Vosmaer Date: Wed, 3 Dec 2014 16:50:03 +0100 Subject: Add changes suggested by Sytse --- doc/release/monthly.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index a95ba2e107b..0700f24ab76 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -217,6 +217,7 @@ It is important to do this as soon as possible, so we can catch any errors befor - Start with a complete copy of the [release blog template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/release_blog_template.md) and fill it out. - Check the changelog of CE and EE for important changes. - Also check the CI changelog +- Add a proposed tweet text to the blog post WIP MR description. - Create a WIP MR for the blog post - Ask Dmitriy to add screenshots to the WIP MR. - Decide with team who will be the MVP user. @@ -264,7 +265,7 @@ Create an issue with description of a problem, if it is quick fix fix it yoursel **NOTE** If there is a problem that cannot be fixed in a timely manner, reverting the feature is an option! If the feature is reverted, create an issue about it in order to discuss the next steps after the release. -# **22nd - Release CE and EE** +# **22nd - Release CE, EE and CI** **Make sure EE `x-x-stable-ee` has latest changes from CE `x-x-stable`** -- cgit v1.2.1 From 90a308ea00ece729b15b430a397d22e3b3fe3102 Mon Sep 17 00:00:00 2001 From: Marin Jankovski Date: Fri, 5 Dec 2014 12:34:18 +0100 Subject: Update release docs to deploy to GitLab.com before publishing. --- doc/release/patch.md | 3 ++- doc/release/security.md | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) (limited to 'doc/release') diff --git a/doc/release/patch.md b/doc/release/patch.md index ce5c2170302..2bd34b7d822 100644 --- a/doc/release/patch.md +++ b/doc/release/patch.md @@ -18,13 +18,14 @@ Otherwise include it in the monthly release and note there was a regression fix 1. Name the issue "Release X.X.X CE and X.X.X EE", this will make searching easier 1. Fix the issue on a feature branch, do this on the private GitLab development server 1. If it is a security issue, then assign it to the release manager and apply a 'security' label +1. Build the package for GitLab.com and do a deploy 1. Consider creating and testing workarounds 1. After the branch is merged into master, cherry pick the commit(s) into the current stable branch 1. Make sure that the build has passed and all tests are passing 1. In a separate commit in the stable branch update the CHANGELOG 1. For EE, update the CHANGELOG-EE if it is EE specific fix. Otherwise, merge the stable CE branch and add to CHANGELOG-EE "Merge community edition changes for version X.X.X" -### Bump version +### Bump version Get release tools diff --git a/doc/release/security.md b/doc/release/security.md index c24a394ef4a..b67e0f37a04 100644 --- a/doc/release/security.md +++ b/doc/release/security.md @@ -17,6 +17,7 @@ Please report suspected security vulnerabilities in private to Date: Mon, 22 Dec 2014 20:58:22 +0100 Subject: Clear responsibility to mention the team. --- doc/release/monthly.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 0700f24ab76..b6f7e8c3b15 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -224,8 +224,8 @@ It is important to do this as soon as possible, so we can catch any errors befor - Create WIP MR for adding MVP to MVP page on website - 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. - Create a merge request on [GitLab.com](https://gitlab.com/gitlab-com/www-gitlab-com/tree/master) -- Assign to one reviewer who will fix spelling issues by editing the branch (can use the online editor) -- After the reviewer is finished the whole team will be mentioned to give their suggestions via line comments +- Assign to one reviewer who will fix spelling issues by editing the branch (either with a git client or by using the online editor) +- Comment to the reviewer: '@person Please mention the whole team as soon as you are done (3 workdays before release at the latest)' ### **4. Create a regressions issue** -- cgit v1.2.1 From e8818da3055d057134e0e26b872c06e3dd9268ff Mon Sep 17 00:00:00 2001 From: Sytse Sijbrandij Date: Tue, 23 Dec 2014 08:37:26 +0100 Subject: Shorter tweet so there is space for a hashtag. --- doc/release/monthly.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 0700f24ab76..7e50da6d174 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -315,7 +315,9 @@ Merge the [blog merge request](#1-prepare-the-blog-post) in `www-gitlab-com` rep Send out a tweet to share the good news with the world. List the most important features and link to the blog post. -Proposed tweet for CE "GitLab X.X is released! It brings *** " +Proposed tweet "Release of GitLab X.X & CI Y.Y! FEATURE, FEATURE and FEATURE #gitlab" + +Consider creating a post on Hacker News. # **1 workday after release - Update GitLab.com** -- cgit v1.2.1 From 6f4332725d0d5feb1062055c6050eef85cfd2aa2 Mon Sep 17 00:00:00 2001 From: Sytse Sijbrandij Date: Tue, 23 Dec 2014 13:39:31 +0100 Subject: Release manager should doublecheck the everyone has been mentioned in the blog post. --- doc/release/monthly.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 98817eeb027..ea7865b4b2b 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -238,7 +238,7 @@ The release manager will comment here about the plans for patch releases. Assign the issue to the release manager and /cc all the core-team members active on the issue tracker. If there are any known bugs in the release add them immediately. -### **4. Tweet** +### **5. Tweet** Tweet about the RC release: @@ -246,6 +246,10 @@ Tweet about the RC release: # **1 workdays before release - Preparation** +### **0. Doublecheck blog post** + +Doublecheck the everyone has been mentioned in the blog post. + ### **1. Pre QA merge** Merge CE into EE before doing the QA. -- cgit v1.2.1 From 4386c210a17e071822126bccfedf0e19fbf1eb0a Mon Sep 17 00:00:00 2001 From: Patricio Cano Date: Tue, 23 Dec 2014 17:28:09 -0500 Subject: Updated the monthly release steps --- doc/release/monthly.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index ea7865b4b2b..b31fd885404 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -200,7 +200,7 @@ Add to your local `gitlab-ci/.git/config`: # **4 workdays before release - Release RC1** -### **1. Determine QA person +### **1. Determine QA person** Notify person of QA day. @@ -215,6 +215,7 @@ It is important to do this as soon as possible, so we can catch any errors befor ### **3. Prepare the blog post** - Start with a complete copy of the [release blog template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/release_blog_template.md) and fill it out. +- Make sure the blog post contains information about the GitLab CI release. - Check the changelog of CE and EE for important changes. - Also check the CI changelog - Add a proposed tweet text to the blog post WIP MR description. @@ -269,7 +270,7 @@ Create an issue with description of a problem, if it is quick fix fix it yoursel **NOTE** If there is a problem that cannot be fixed in a timely manner, reverting the feature is an option! If the feature is reverted, create an issue about it in order to discuss the next steps after the release. -# **22nd - Release CE, EE and CI** +# **Workday before release - Create Omnibus tags and build packages** **Make sure EE `x-x-stable-ee` has latest changes from CE `x-x-stable`** @@ -306,15 +307,17 @@ Follow the [release doc in the Omnibus repository](https://gitlab.com/gitlab-org This can happen before tagging because Omnibus uses tags in its own repo and SHA1's to refer to the GitLab codebase. -### **4. Publish packages for new release** +# **22nd - Release CE, EE and CI** + +### **1. Publish packages for new release** Update `downloads/index.html` and `downloads/archive/index.html` in `www-gitlab-com` repository. -### **5. Publish blog for new release** +### **2. Publish blog for new release** Merge the [blog merge request](#1-prepare-the-blog-post) in `www-gitlab-com` repository. -### **6. Tweet to blog** +### **3. Tweet to blog** Send out a tweet to share the good news with the world. List the most important features and link to the blog post. -- cgit v1.2.1 From 3c19929c757e5ff45f5afa3713002ee1862c0b75 Mon Sep 17 00:00:00 2001 From: Dmitriy Zaporozhets Date: Fri, 9 Jan 2015 12:29:48 -0800 Subject: Cleanup and refactor release doc. Follow issue as a todo list --- doc/release/howto_rc1.md | 126 +++++++++++++++++++++++ doc/release/monthly.md | 263 ++++++++++++----------------------------------- 2 files changed, 190 insertions(+), 199 deletions(-) create mode 100644 doc/release/howto_rc1.md (limited to 'doc/release') diff --git a/doc/release/howto_rc1.md b/doc/release/howto_rc1.md new file mode 100644 index 00000000000..2bfc23951ec --- /dev/null +++ b/doc/release/howto_rc1.md @@ -0,0 +1,126 @@ +# How to create 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. Update the installation guide** + +1. Check if it references the correct branch `x-x-stable` (doesn't exist yet, but that is okay) +1. Check the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782) +1. Check the [Git version](/lib/tasks/gitlab/check.rake#L794) +1. There might be other changes. Ask around. + +### **2. Create update guides** + +1. Create: CE update guide from previous version. Like `7.3-to-7.4.md` +1. Create: CE to EE update guide in EE repository for latest version. +1. Update: `6.x-or-7.x-to-7.x.md` to latest version. +1. Create: CI update guide from previous version + +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. Stop server + +#### 2. Make backup + +#### 3. Do users need to update dependencies like `git`? + +- Check if the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782) changed since the last release. + +- Check if the [Git version](/lib/tasks/gitlab/check.rake#L794) changed since the last release. + +#### 4. Get latest code + +#### 5. Does GitLab shell need to be updated? + +#### 6. Install libs, migrations, etc. + +#### 7. Any config files updated since last release? + +Check if any of these changed since last release: + +- [lib/support/nginx/gitlab](/lib/support/nginx/gitlab) +- [lib/support/nginx/gitlab-ssl](/lib/support/nginx/gitlab-ssl) +- +- [config/gitlab.yml.example](/config/gitlab.yml.example) +- [config/unicorn.rb.example](/config/unicorn.rb.example) +- [config/database.yml.mysql](/config/database.yml.mysql) +- [config/database.yml.postgresql](/config/database.yml.postgresql) +- [config/initializers/rack_attack.rb.example](/config/initializers/rack_attack.rb.example) +- [config/resque.yml.example](/config/resque.yml.example) + +#### 8. Need to update init script? + +Check if the `init.d/gitlab` script changed since last release: [lib/support/init.d/gitlab](/lib/support/init.d/gitlab) + +#### 9. Start application + +#### 10. Check application status + +### **3. Code quality indicators** + +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) + +- [![Build Status](https://semaphoreapp.com/api/v1/projects/2f1a5809-418b-4cc2-a1f4-819607579fe7/243338/badge.png)](https://semaphoreapp.com/gitlabhq/gitlabhq) (master branch) + +- [![Code Climate](https://codeclimate.com/github/gitlabhq/gitlabhq.png)](https://codeclimate.com/github/gitlabhq/gitlabhq) + +- [![Dependency Status](https://gemnasium.com/gitlabhq/gitlabhq.png)](https://gemnasium.com/gitlabhq/gitlabhq) this button can be yellow (small updates are available) but must not be red (a security fix or an important update is available) + +- [![Coverage Status](https://coveralls.io/repos/gitlabhq/gitlabhq/badge.png?branch=master)](https://coveralls.io/r/gitlabhq/gitlabhq) + +### 4. Run release tool for CE and EE + +**Make sure EE `master` has latest changes from CE `master`** + +Get release tools + +``` +git clone git@dev.gitlab.org:gitlab/release-tools.git +cd release-tools +``` + +Release candidate creates stable branch from master. +So we need to sync master branch between all CE remotes. Also do same for EE. + +``` +bundle exec rake sync +``` + +Create release candidate and stable branch: + +``` +bundle exec rake release["x.x.0.rc1"] +``` + +Now developers can use master for merging new features. +So you should use stable branch for future code chages related to release. + + +### 5. Release GitLab CI RC1 + +Add to your local `gitlab-ci/.git/config`: + +``` +[remote "public"] + url = none + pushurl = git@dev.gitlab.org:gitlab/gitlab-ci.git + pushurl = git@gitlab.com:gitlab-org/gitlab-ci.git + pushurl = git@github.com:gitlabhq/gitlab-ci.git +``` + +* Create a stable branch `x-y-stable` +* Bump VERSION to `x.y.0.rc1` +* `git tag -a v$(cat VERSION) -m "Version $(cat VERSION)" +* `git push public x-y-stable v$(cat VERSION)` + diff --git a/doc/release/monthly.md b/doc/release/monthly.md index b31fd885404..810f992cafb 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -2,209 +2,90 @@ NOTE: This is a guide for GitLab developers. -# **7 workdays before release - Code Freeze & Release Manager** +It starts 7 days before release. Current release manager must choose next release manager. +New release manager should create overall issue at GitLab -### **1. Stop merging in code, except for important bug fixes** -### **2. Release Manager** +## Release Manager A release manager is selected that coordinates all releases the coming month, including the patch releases for previous releases. 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. -### **3. Create an overall issue** +## Take weekend and vacations into account + +Ensure that there is enough time to incorporate the findings of the release candidate, etc. + +## Create an overall issue and follow it Create issue for GitLab CE project(internal). Name it "Release x.x.x" for easier searching. Replace the dates with actual dates based on the number of workdays before the release. +All steps from issue template are explained below ``` -Xth: +Xth: (7 working days befor 22th) +- [ ] Code freeze - [ ] Update the CE changelog (#LINK) - [ ] Update the EE changelog (#LINK) - [ ] Update the CI changelog (#LINK) - [ ] Triage the omnibus-gitlab milestone -Xth: +Xth: (6 working days befor 22th) -- [ ] Merge CE in to EE (#LINK) -- [ ] Close the omnibus-gitlab milestone +- [ ] Merge CE master in to EE master via merge request (#LINK) +- [ ] Create CE, EE, CI RC1 versions (#LINK) -Xth: +Xth: (5 working days befor 22th) -- [ ] Create x.x.0.rc1 (#LINK) -- [ ] Create x.x.0.rc1-ee (#LINK) -- [ ] Create CI y.y.0.rc1 (#LINK) -- [ ] Build package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package) +- [ ] Close the omnibus-gitlab milestone +- [ ] Build rc1 package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package) -Xth: +Xth: (4 working days befor 22th) - [ ] Update GitLab.com with rc1 (#LINK) (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#deploy-the-package) -- [ ] Regression issues (CE, CI) and tweet about rc1 (#LINK) +- [ ] Create regression issues (CE, CI) (#LINK) +- [ ] Tweet about rc1 (#LINK) - [ ] Start blog post (#LINK) +- [ ] Determine QA person and notify him -Xth: +Xth: (2 working days befor 22th) +- [ ] Merge CE stable branch into EE stable branch - [ ] Do QA and fix anything coming out of it (#LINK) +Xth: (1 working day befor 22th) + +- [ ] Create CE, EE, CI stable versions (#LINK) +- [ ] Create Omnibus tags and build packages + 22nd: - [ ] Release CE, EE and CI (#LINK) -Xth: +Xth: (1 working day after 22th) - [ ] Deploy to GitLab.com (#LINK) ``` -### **4. Update changelog** - -Any changes not yet added to the changelog are added by lead developer and in that merge request the complete team is asked if there is anything missing. - -There are three changelogs that need to be updated: CE, EE and CI. - -### **5. Take weekend and vacations into account** - -Ensure that there is enough time to incorporate the findings of the release candidate, etc. - -# **6 workdays before release- Merge the CE into EE** - -Do this via a merge request. - -# **5 workdays before release - Create 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. Update the installation guide** - -1. Check if it references the correct branch `x-x-stable` (doesn't exist yet, but that is okay) -1. Check the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782) -1. Check the [Git version](/lib/tasks/gitlab/check.rake#L794) -1. There might be other changes. Ask around. - -### **2. Create update guides** - -1. Create: CE update guide from previous version. Like `7.3-to-7.4.md` -1. Create: CE to EE update guide in EE repository for latest version. -1. Update: `6.x-or-7.x-to-7.x.md` to latest version. -1. Create: CI update guide from previous version - -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. Stop server - -#### 2. Make backup +- - - -#### 3. Do users need to update dependencies like `git`? +## Code Freeze -- Check if the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782) changed since the last release. - -- Check if the [Git version](/lib/tasks/gitlab/check.rake#L794) changed since the last release. - -#### 4. Get latest code - -#### 5. Does GitLab shell need to be updated? - -#### 6. Install libs, migrations, etc. - -#### 7. Any config files updated since last release? - -Check if any of these changed since last release: - -- [lib/support/nginx/gitlab](/lib/support/nginx/gitlab) -- [lib/support/nginx/gitlab-ssl](/lib/support/nginx/gitlab-ssl) -- -- [config/gitlab.yml.example](/config/gitlab.yml.example) -- [config/unicorn.rb.example](/config/unicorn.rb.example) -- [config/database.yml.mysql](/config/database.yml.mysql) -- [config/database.yml.postgresql](/config/database.yml.postgresql) -- [config/initializers/rack_attack.rb.example](/config/initializers/rack_attack.rb.example) -- [config/resque.yml.example](/config/resque.yml.example) - -#### 8. Need to update init script? - -Check if the `init.d/gitlab` script changed since last release: [lib/support/init.d/gitlab](/lib/support/init.d/gitlab) - -#### 9. Start application - -#### 10. Check application status - -### **3. Code quality indicators** - -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) - -- [![Build Status](https://semaphoreapp.com/api/v1/projects/2f1a5809-418b-4cc2-a1f4-819607579fe7/243338/badge.png)](https://semaphoreapp.com/gitlabhq/gitlabhq) (master branch) - -- [![Code Climate](https://codeclimate.com/github/gitlabhq/gitlabhq.png)](https://codeclimate.com/github/gitlabhq/gitlabhq) - -- [![Dependency Status](https://gemnasium.com/gitlabhq/gitlabhq.png)](https://gemnasium.com/gitlabhq/gitlabhq) this button can be yellow (small updates are available) but must not be red (a security fix or an important update is available) - -- [![Coverage Status](https://coveralls.io/repos/gitlabhq/gitlabhq/badge.png?branch=master)](https://coveralls.io/r/gitlabhq/gitlabhq) - -### **4. Run release tool** - -**Make sure EE `master` has latest changes from CE `master`** - -Get release tools - -``` -git clone git@dev.gitlab.org:gitlab/release-tools.git -cd release-tools -``` +Stop merging code in master, except for important bug fixes -Release candidate creates stable branch from master. -So we need to sync master branch between all CE remotes. Also do same for EE. - -``` -bundle exec rake sync -``` - -Create release candidate and stable branch: - -``` -bundle exec rake release["x.x.0.rc1"] -``` - -Now developers can use master for merging new features. -So you should use stable branch for future code chages related to release. - - -### 5. Release GitLab CI RC1 - -Add to your local `gitlab-ci/.git/config`: - -``` -[remote "public"] - url = none - pushurl = git@dev.gitlab.org:gitlab/gitlab-ci.git - pushurl = git@gitlab.com:gitlab-org/gitlab-ci.git - pushurl = git@github.com:gitlabhq/gitlab-ci.git -``` - -* Create a stable branch `x-y-stable` -* Bump VERSION to `x.y.0.rc1` -* `git tag -a v$(cat VERSION) -m "Version $(cat VERSION)" -* `git push public x-y-stable v$(cat VERSION)` +## Update changelog +Any changes not yet added to the changelog are added by lead developer and in that merge request the complete team is asked if there is anything missing. -# **4 workdays before release - Release RC1** +There are three changelogs that need to be updated: CE, EE and CI. -### **1. Determine QA person** +## Create RC1 (CE, EE, CI) -Notify person of QA day. +[Follow this How-to guide](howto_rc1.md) to create RC1. -### **2. Update GitLab.com** +## Update GitLab.com with RC1 Merge the RC1 EE code into GitLab.com. Once the build is green, create a package. @@ -212,23 +93,7 @@ If there are big database migrations consider testing them with the production d Try to 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. -### **3. Prepare the blog post** - -- Start with a complete copy of the [release blog template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/release_blog_template.md) and fill it out. -- Make sure the blog post contains information about the GitLab CI release. -- Check the changelog of CE and EE for important changes. -- Also check the CI changelog -- Add a proposed tweet text to the blog post WIP MR description. -- Create a WIP MR for the blog post -- Ask Dmitriy to add screenshots to the WIP MR. -- Decide with team who will be the MVP user. -- Create WIP MR for adding MVP to MVP page on website -- 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. -- Create a merge request on [GitLab.com](https://gitlab.com/gitlab-com/www-gitlab-com/tree/master) -- Assign to one reviewer who will fix spelling issues by editing the branch (either with a git client or by using the online editor) -- Comment to the reviewer: '@person Please mention the whole team as soon as you are done (3 workdays before release at the latest)' - -### **4. Create a regressions issue** +## Create a regressions issue On [the GitLab CE issue tracker on GitLab.com](https://gitlab.com/gitlab-org/gitlab-ce/issues/) create an issue titled "GitLab X.X regressions" add the following text: @@ -239,23 +104,29 @@ The release manager will comment here about the plans for patch releases. Assign the issue to the release manager and /cc all the core-team members active on the issue tracker. If there are any known bugs in the release add them immediately. -### **5. Tweet** +## Tweet about RC1 Tweet about the RC release: > GitLab x.x.0.rc1 is out. This release candidate is only suitable for testing. Please link regressions issues from LINK_TO_REGRESSION_ISSUE -# **1 workdays before release - Preparation** - -### **0. Doublecheck blog post** - -Doublecheck the everyone has been mentioned in the blog post. - -### **1. Pre QA merge** +## Prepare the blog post -Merge CE into EE before doing the QA. +- Start with a complete copy of the [release blog template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/release_blog_template.md) and fill it out. +- Make sure the blog post contains information about the GitLab CI release. +- Check the changelog of CE and EE for important changes. +- Also check the CI changelog +- Add a proposed tweet text to the blog post WIP MR description. +- Create a WIP MR for the blog post +- Ask Dmitriy to add screenshots to the WIP MR. +- Decide with team who will be the MVP user. +- Create WIP MR for adding MVP to MVP page on website +- 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. +- Create a merge request on [GitLab.com](https://gitlab.com/gitlab-com/www-gitlab-com/tree/master) +- Assign to one reviewer who will fix spelling issues by editing the branch (either with a git client or by using the online editor) +- Comment to the reviewer: '@person Please mention the whole team as soon as you are done (3 workdays before release at the latest)' -### **2. QA** +## QA Create issue on dev.gitlab.org `gitlab` repository, named "GitLab X.X QA" in order to keep track of the progress. @@ -263,19 +134,14 @@ Use the omnibus packages of Enterprise Edition using [this guide](https://dev.gi **NOTE** Upgrader can only be tested when tags are pushed to all repositories. Do not forget to confirm it is working before releasing. Note that in the issue. -### **3. Fix anything coming out of the QA** +#### Fix anything coming out of the QA Create an issue with description of a problem, if it is quick fix fix it yourself otherwise contact the team for advice. **NOTE** If there is a problem that cannot be fixed in a timely manner, reverting the feature is an option! If the feature is reverted, create an issue about it in order to discuss the next steps after the release. -# **Workday before release - Create Omnibus tags and build packages** - -**Make sure EE `x-x-stable-ee` has latest changes from CE `x-x-stable`** - - -### **1. Release code** +## Create CE, EE, CI stable versions Get release tools @@ -296,28 +162,27 @@ Also perform these steps for GitLab CI: - create annotated tag - push the stable branch and the annotated tag to the public repositories -### **2. Update installation.md** - Update [installation.md](/doc/install/installation.md) to the newest version in master. -### **3. Build the Omnibus packages** +## Create Omnibus tags and build packages Follow the [release doc in the Omnibus repository](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/release.md). This can happen before tagging because Omnibus uses tags in its own repo and SHA1's to refer to the GitLab codebase. -# **22nd - Release CE, EE and CI** +## Release CE, EE and CI -### **1. Publish packages for new release** +### 1. Publish packages for new release Update `downloads/index.html` and `downloads/archive/index.html` in `www-gitlab-com` repository. -### **2. Publish blog for new release** +### 2. Publish blog for new release +Doublecheck the everyone has been mentioned in the blog post. Merge the [blog merge request](#1-prepare-the-blog-post) in `www-gitlab-com` repository. -### **3. Tweet to blog** +### 3. Tweet to blog Send out a tweet to share the good news with the world. List the most important features and link to the blog post. @@ -326,7 +191,7 @@ Proposed tweet "Release of GitLab X.X & CI Y.Y! FEATURE, FEATURE and FEATURE
  • Date: Sat, 10 Jan 2015 02:12:00 +0000 Subject: Improve monthly.md with fixes proposed from @sytse --- doc/release/monthly.md | 48 +++++++++++++++++++++++++++--------------------- 1 file changed, 27 insertions(+), 21 deletions(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 810f992cafb..917dc7f6934 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -14,7 +14,9 @@ This person should also make sure this document is kept up to date and issues ar ## Take weekend and vacations into account -Ensure that there is enough time to incorporate the findings of the release candidate, etc. +The time is measured in weekdays to compensate for weekends. +Do things on time to prevent problems due to rush jobs or too little testing time. +Make sure that you take into account vacations of maintainers. ## Create an overall issue and follow it @@ -35,24 +37,29 @@ Xth: (6 working days befor 22th) - [ ] Merge CE master in to EE master via merge request (#LINK) - [ ] Create CE, EE, CI RC1 versions (#LINK) +- [ ] Determine QA person and notify this person Xth: (5 working days befor 22th) +- [ ] Do QA and fix anything coming out of it (#LINK) - [ ] Close the omnibus-gitlab milestone -- [ ] Build rc1 package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package) Xth: (4 working days befor 22th) +- [ ] Build rc1 package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package) - [ ] Update GitLab.com with rc1 (#LINK) (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#deploy-the-package) + +Xth: (3 working days befor 22th) + - [ ] Create regression issues (CE, CI) (#LINK) - [ ] Tweet about rc1 (#LINK) -- [ ] Start blog post (#LINK) -- [ ] Determine QA person and notify him +- [ ] Prepare the blog post (#LINK) + Xth: (2 working days befor 22th) - [ ] Merge CE stable branch into EE stable branch -- [ ] Do QA and fix anything coming out of it (#LINK) +- [ ] Check that everyone is mentioned on the blog post (the reviewer should have done this one working day ago) Xth: (1 working day befor 22th) @@ -85,6 +92,21 @@ There are three changelogs that need to be updated: CE, EE and CI. [Follow this How-to guide](howto_rc1.md) to create RC1. +## QA + +Create issue on dev.gitlab.org `gitlab` repository, named "GitLab X.X QA" in order to keep track of the progress. + +Use the omnibus packages of Enterprise Edition using [this guide](https://dev.gitlab.org/gitlab/gitlab-ee/blob/master/doc/release/manual_testing.md). + +**NOTE** Upgrader can only be tested when tags are pushed to all repositories. Do not forget to confirm it is working before releasing. Note that in the issue. + +#### Fix anything coming out of the QA + +Create an issue with description of a problem, if it is quick fix fix it yourself otherwise contact the team for advice. + +**NOTE** If there is a problem that cannot be fixed in a timely manner, reverting the feature is an option! If the feature is reverted, +create an issue about it in order to discuss the next steps after the release. + ## Update GitLab.com with RC1 Merge the RC1 EE code into GitLab.com. @@ -126,21 +148,6 @@ Tweet about the RC release: - Assign to one reviewer who will fix spelling issues by editing the branch (either with a git client or by using the online editor) - Comment to the reviewer: '@person Please mention the whole team as soon as you are done (3 workdays before release at the latest)' -## QA - -Create issue on dev.gitlab.org `gitlab` repository, named "GitLab X.X QA" in order to keep track of the progress. - -Use the omnibus packages of Enterprise Edition using [this guide](https://dev.gitlab.org/gitlab/gitlab-ee/blob/master/doc/release/manual_testing.md). - -**NOTE** Upgrader can only be tested when tags are pushed to all repositories. Do not forget to confirm it is working before releasing. Note that in the issue. - -#### Fix anything coming out of the QA - -Create an issue with description of a problem, if it is quick fix fix it yourself otherwise contact the team for advice. - -**NOTE** If there is a problem that cannot be fixed in a timely manner, reverting the feature is an option! If the feature is reverted, -create an issue about it in order to discuss the next steps after the release. - ## Create CE, EE, CI stable versions Get release tools @@ -193,5 +200,4 @@ Consider creating a post on Hacker News. ## Update GitLab.com with stable version -- Build a package for gitlab.com based on the official release instead of RC1 - Deploy the package (should not need downtime because of the small difference with RC1) -- cgit v1.2.1 From b9dd52dd14a98b69db0537fa3431fe6a01a3284d Mon Sep 17 00:00:00 2001 From: Dmitriy Zaporozhets Date: Sat, 10 Jan 2015 02:13:09 +0000 Subject: Improve monthly.md with fixes proposed from Sytse --- doc/release/monthly.md | 48 +++++++++++++++++++++--------------------------- 1 file changed, 21 insertions(+), 27 deletions(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 917dc7f6934..810f992cafb 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -14,9 +14,7 @@ This person should also make sure this document is kept up to date and issues ar ## Take weekend and vacations into account -The time is measured in weekdays to compensate for weekends. -Do things on time to prevent problems due to rush jobs or too little testing time. -Make sure that you take into account vacations of maintainers. +Ensure that there is enough time to incorporate the findings of the release candidate, etc. ## Create an overall issue and follow it @@ -37,29 +35,24 @@ Xth: (6 working days befor 22th) - [ ] Merge CE master in to EE master via merge request (#LINK) - [ ] Create CE, EE, CI RC1 versions (#LINK) -- [ ] Determine QA person and notify this person Xth: (5 working days befor 22th) -- [ ] Do QA and fix anything coming out of it (#LINK) - [ ] Close the omnibus-gitlab milestone +- [ ] Build rc1 package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package) Xth: (4 working days befor 22th) -- [ ] Build rc1 package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package) - [ ] Update GitLab.com with rc1 (#LINK) (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#deploy-the-package) - -Xth: (3 working days befor 22th) - - [ ] Create regression issues (CE, CI) (#LINK) - [ ] Tweet about rc1 (#LINK) -- [ ] Prepare the blog post (#LINK) - +- [ ] Start blog post (#LINK) +- [ ] Determine QA person and notify him Xth: (2 working days befor 22th) - [ ] Merge CE stable branch into EE stable branch -- [ ] Check that everyone is mentioned on the blog post (the reviewer should have done this one working day ago) +- [ ] Do QA and fix anything coming out of it (#LINK) Xth: (1 working day befor 22th) @@ -92,21 +85,6 @@ There are three changelogs that need to be updated: CE, EE and CI. [Follow this How-to guide](howto_rc1.md) to create RC1. -## QA - -Create issue on dev.gitlab.org `gitlab` repository, named "GitLab X.X QA" in order to keep track of the progress. - -Use the omnibus packages of Enterprise Edition using [this guide](https://dev.gitlab.org/gitlab/gitlab-ee/blob/master/doc/release/manual_testing.md). - -**NOTE** Upgrader can only be tested when tags are pushed to all repositories. Do not forget to confirm it is working before releasing. Note that in the issue. - -#### Fix anything coming out of the QA - -Create an issue with description of a problem, if it is quick fix fix it yourself otherwise contact the team for advice. - -**NOTE** If there is a problem that cannot be fixed in a timely manner, reverting the feature is an option! If the feature is reverted, -create an issue about it in order to discuss the next steps after the release. - ## Update GitLab.com with RC1 Merge the RC1 EE code into GitLab.com. @@ -148,6 +126,21 @@ Tweet about the RC release: - Assign to one reviewer who will fix spelling issues by editing the branch (either with a git client or by using the online editor) - Comment to the reviewer: '@person Please mention the whole team as soon as you are done (3 workdays before release at the latest)' +## QA + +Create issue on dev.gitlab.org `gitlab` repository, named "GitLab X.X QA" in order to keep track of the progress. + +Use the omnibus packages of Enterprise Edition using [this guide](https://dev.gitlab.org/gitlab/gitlab-ee/blob/master/doc/release/manual_testing.md). + +**NOTE** Upgrader can only be tested when tags are pushed to all repositories. Do not forget to confirm it is working before releasing. Note that in the issue. + +#### Fix anything coming out of the QA + +Create an issue with description of a problem, if it is quick fix fix it yourself otherwise contact the team for advice. + +**NOTE** If there is a problem that cannot be fixed in a timely manner, reverting the feature is an option! If the feature is reverted, +create an issue about it in order to discuss the next steps after the release. + ## Create CE, EE, CI stable versions Get release tools @@ -200,4 +193,5 @@ Consider creating a post on Hacker News. ## Update GitLab.com with stable version +- Build a package for gitlab.com based on the official release instead of RC1 - Deploy the package (should not need downtime because of the small difference with RC1) -- cgit v1.2.1 From c736968695d2b2e0bd3be16fda2287e02966d9b2 Mon Sep 17 00:00:00 2001 From: Dmitriy Zaporozhets Date: Sat, 10 Jan 2015 02:14:45 +0000 Subject: Improve monthly.md with fixes proposed from Sytse --- doc/release/monthly.md | 48 +++++++++++++++++++++++++++--------------------- 1 file changed, 27 insertions(+), 21 deletions(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 810f992cafb..917dc7f6934 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -14,7 +14,9 @@ This person should also make sure this document is kept up to date and issues ar ## Take weekend and vacations into account -Ensure that there is enough time to incorporate the findings of the release candidate, etc. +The time is measured in weekdays to compensate for weekends. +Do things on time to prevent problems due to rush jobs or too little testing time. +Make sure that you take into account vacations of maintainers. ## Create an overall issue and follow it @@ -35,24 +37,29 @@ Xth: (6 working days befor 22th) - [ ] Merge CE master in to EE master via merge request (#LINK) - [ ] Create CE, EE, CI RC1 versions (#LINK) +- [ ] Determine QA person and notify this person Xth: (5 working days befor 22th) +- [ ] Do QA and fix anything coming out of it (#LINK) - [ ] Close the omnibus-gitlab milestone -- [ ] Build rc1 package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package) Xth: (4 working days befor 22th) +- [ ] Build rc1 package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package) - [ ] Update GitLab.com with rc1 (#LINK) (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#deploy-the-package) + +Xth: (3 working days befor 22th) + - [ ] Create regression issues (CE, CI) (#LINK) - [ ] Tweet about rc1 (#LINK) -- [ ] Start blog post (#LINK) -- [ ] Determine QA person and notify him +- [ ] Prepare the blog post (#LINK) + Xth: (2 working days befor 22th) - [ ] Merge CE stable branch into EE stable branch -- [ ] Do QA and fix anything coming out of it (#LINK) +- [ ] Check that everyone is mentioned on the blog post (the reviewer should have done this one working day ago) Xth: (1 working day befor 22th) @@ -85,6 +92,21 @@ There are three changelogs that need to be updated: CE, EE and CI. [Follow this How-to guide](howto_rc1.md) to create RC1. +## QA + +Create issue on dev.gitlab.org `gitlab` repository, named "GitLab X.X QA" in order to keep track of the progress. + +Use the omnibus packages of Enterprise Edition using [this guide](https://dev.gitlab.org/gitlab/gitlab-ee/blob/master/doc/release/manual_testing.md). + +**NOTE** Upgrader can only be tested when tags are pushed to all repositories. Do not forget to confirm it is working before releasing. Note that in the issue. + +#### Fix anything coming out of the QA + +Create an issue with description of a problem, if it is quick fix fix it yourself otherwise contact the team for advice. + +**NOTE** If there is a problem that cannot be fixed in a timely manner, reverting the feature is an option! If the feature is reverted, +create an issue about it in order to discuss the next steps after the release. + ## Update GitLab.com with RC1 Merge the RC1 EE code into GitLab.com. @@ -126,21 +148,6 @@ Tweet about the RC release: - Assign to one reviewer who will fix spelling issues by editing the branch (either with a git client or by using the online editor) - Comment to the reviewer: '@person Please mention the whole team as soon as you are done (3 workdays before release at the latest)' -## QA - -Create issue on dev.gitlab.org `gitlab` repository, named "GitLab X.X QA" in order to keep track of the progress. - -Use the omnibus packages of Enterprise Edition using [this guide](https://dev.gitlab.org/gitlab/gitlab-ee/blob/master/doc/release/manual_testing.md). - -**NOTE** Upgrader can only be tested when tags are pushed to all repositories. Do not forget to confirm it is working before releasing. Note that in the issue. - -#### Fix anything coming out of the QA - -Create an issue with description of a problem, if it is quick fix fix it yourself otherwise contact the team for advice. - -**NOTE** If there is a problem that cannot be fixed in a timely manner, reverting the feature is an option! If the feature is reverted, -create an issue about it in order to discuss the next steps after the release. - ## Create CE, EE, CI stable versions Get release tools @@ -193,5 +200,4 @@ Consider creating a post on Hacker News. ## Update GitLab.com with stable version -- Build a package for gitlab.com based on the official release instead of RC1 - Deploy the package (should not need downtime because of the small difference with RC1) -- cgit v1.2.1 From 2e3749cdccfd2eb2e596980e16b88a604e97834e Mon Sep 17 00:00:00 2001 From: Dmitriy Zaporozhets Date: Sun, 11 Jan 2015 01:32:42 +0000 Subject: Replace befor with before --- doc/release/monthly.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 917dc7f6934..20a9392747c 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -25,7 +25,7 @@ Replace the dates with actual dates based on the number of workdays before the r All steps from issue template are explained below ``` -Xth: (7 working days befor 22th) +Xth: (7 working days before 22th) - [ ] Code freeze - [ ] Update the CE changelog (#LINK) @@ -33,35 +33,35 @@ Xth: (7 working days befor 22th) - [ ] Update the CI changelog (#LINK) - [ ] Triage the omnibus-gitlab milestone -Xth: (6 working days befor 22th) +Xth: (6 working days before 22th) - [ ] Merge CE master in to EE master via merge request (#LINK) - [ ] Create CE, EE, CI RC1 versions (#LINK) - [ ] Determine QA person and notify this person -Xth: (5 working days befor 22th) +Xth: (5 working days before 22th) - [ ] Do QA and fix anything coming out of it (#LINK) - [ ] Close the omnibus-gitlab milestone -Xth: (4 working days befor 22th) +Xth: (4 working days before 22th) - [ ] Build rc1 package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package) - [ ] Update GitLab.com with rc1 (#LINK) (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#deploy-the-package) -Xth: (3 working days befor 22th) +Xth: (3 working days before 22th) - [ ] Create regression issues (CE, CI) (#LINK) - [ ] Tweet about rc1 (#LINK) - [ ] Prepare the blog post (#LINK) -Xth: (2 working days befor 22th) +Xth: (2 working days before 22th) - [ ] Merge CE stable branch into EE stable branch - [ ] Check that everyone is mentioned on the blog post (the reviewer should have done this one working day ago) -Xth: (1 working day befor 22th) +Xth: (1 working day before 22th) - [ ] Create CE, EE, CI stable versions (#LINK) - [ ] Create Omnibus tags and build packages -- cgit v1.2.1 From 1c3c8a9c55457a3147d5da7431505ecf87f70007 Mon Sep 17 00:00:00 2001 From: Dmitriy Zaporozhets Date: Sun, 11 Jan 2015 01:34:35 +0000 Subject: Make ordered lists for release doc --- doc/release/monthly.md | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 20a9392747c..c0f66964a9a 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -134,19 +134,19 @@ Tweet about the RC release: ## Prepare the blog post -- Start with a complete copy of the [release blog template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/release_blog_template.md) and fill it out. -- Make sure the blog post contains information about the GitLab CI release. -- Check the changelog of CE and EE for important changes. -- Also check the CI changelog -- Add a proposed tweet text to the blog post WIP MR description. -- Create a WIP MR for the blog post -- Ask Dmitriy to add screenshots to the WIP MR. -- Decide with team who will be the MVP user. -- Create WIP MR for adding MVP to MVP page on website -- 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. -- Create a merge request on [GitLab.com](https://gitlab.com/gitlab-com/www-gitlab-com/tree/master) -- Assign to one reviewer who will fix spelling issues by editing the branch (either with a git client or by using the online editor) -- Comment to the reviewer: '@person Please mention the whole team as soon as you are done (3 workdays before release at the latest)' +1. Start with a complete copy of the [release blog template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/release_blog_template.md) and fill it out. +1. Make sure the blog post contains information about the GitLab CI release. +1. Check the changelog of CE and EE for important changes. +1. Also check the CI changelog +1. Add a proposed tweet text to the blog post WIP MR description. +1. Create a WIP MR for the blog post +1. Ask Dmitriy to add screenshots to the WIP MR. +1. Decide with team who will be the MVP user. +1. Create WIP MR for adding MVP to MVP page on website +1. 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. +1. Create a merge request on [GitLab.com](https://gitlab.com/gitlab-com/www-gitlab-com/tree/master) +1. Assign to one reviewer who will fix spelling issues by editing the branch (either with a git client or by using the online editor) +1. Comment to the reviewer: '@person Please mention the whole team as soon as you are done (3 workdays before release at the latest)' ## Create CE, EE, CI stable versions @@ -165,9 +165,9 @@ bundle exec rake release["x.x.0"] Also perform these steps for GitLab CI: -- bump version in the stable branch -- create annotated tag -- push the stable branch and the annotated tag to the public repositories +1. bump version in the stable branch +1. create annotated tag +1. push the stable branch and the annotated tag to the public repositories Update [installation.md](/doc/install/installation.md) to the newest version in master. @@ -180,16 +180,16 @@ This can happen before tagging because Omnibus uses tags in its own repo and SHA ## Release CE, EE and CI -### 1. Publish packages for new release +__1. Publish packages for new release__ Update `downloads/index.html` and `downloads/archive/index.html` in `www-gitlab-com` repository. -### 2. Publish blog for new release +__2. Publish blog for new release__ Doublecheck the everyone has been mentioned in the blog post. Merge the [blog merge request](#1-prepare-the-blog-post) in `www-gitlab-com` repository. -### 3. Tweet to blog +__3. Tweet to blog__ Send out a tweet to share the good news with the world. List the most important features and link to the blog post. -- cgit v1.2.1 From 37163d7c750c4e517dd0cc08707e690bb6a23730 Mon Sep 17 00:00:00 2001 From: Sytse Sijbrandij Date: Sat, 10 Jan 2015 19:28:50 -0800 Subject: Small spelling improvements. --- doc/release/monthly.md | 37 +++++++++++++++++++------------------ 1 file changed, 19 insertions(+), 18 deletions(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index c0f66964a9a..42a7e96ec35 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -1,10 +1,11 @@ # Monthly Release -NOTE: This is a guide for GitLab developers. - -It starts 7 days before release. Current release manager must choose next release manager. -New release manager should create overall issue at GitLab +NOTE: This is a guide used by the GitLab B.V. developers. +It starts 7 working days before the release. +The release manager doesn't have to perform all the work but must ensure someone is assigned. +The current release manager must schedule the appointment of the next release manager. +The new release manager should create overall issue to track the progress. ## Release Manager @@ -12,11 +13,12 @@ A release manager is selected that coordinates all releases the coming month, in 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. -## Take weekend and vacations into account +## Take vacations into account The time is measured in weekdays to compensate for weekends. -Do things on time to prevent problems due to rush jobs or too little testing time. -Make sure that you take into account vacations of maintainers. +Do everything on time to prevent problems due to rush jobs or too little testing time. +Make sure that you take into account any vacations of maintainers. +If the release is falling behind immediately warn the team. ## Create an overall issue and follow it @@ -25,7 +27,7 @@ Replace the dates with actual dates based on the number of workdays before the r All steps from issue template are explained below ``` -Xth: (7 working days before 22th) +Xth: (7 working days before the 22nd) - [ ] Code freeze - [ ] Update the CE changelog (#LINK) @@ -33,35 +35,34 @@ Xth: (7 working days before 22th) - [ ] Update the CI changelog (#LINK) - [ ] Triage the omnibus-gitlab milestone -Xth: (6 working days before 22th) +Xth: (6 working days before the 22nd) - [ ] Merge CE master in to EE master via merge request (#LINK) - [ ] Create CE, EE, CI RC1 versions (#LINK) - [ ] Determine QA person and notify this person -Xth: (5 working days before 22th) +Xth: (5 working days before the 22nd) - [ ] Do QA and fix anything coming out of it (#LINK) - [ ] Close the omnibus-gitlab milestone -Xth: (4 working days before 22th) +Xth: (4 working days before the 22nd) - [ ] Build rc1 package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package) - [ ] Update GitLab.com with rc1 (#LINK) (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#deploy-the-package) -Xth: (3 working days before 22th) +Xth: (3 working days before the 22nd) - [ ] Create regression issues (CE, CI) (#LINK) - [ ] Tweet about rc1 (#LINK) - [ ] Prepare the blog post (#LINK) - -Xth: (2 working days before 22th) +Xth: (2 working days before the 22nd) - [ ] Merge CE stable branch into EE stable branch - [ ] Check that everyone is mentioned on the blog post (the reviewer should have done this one working day ago) -Xth: (1 working day before 22th) +Xth: (1 working day before the 22nd) - [ ] Create CE, EE, CI stable versions (#LINK) - [ ] Create Omnibus tags and build packages @@ -70,9 +71,9 @@ Xth: (1 working day before 22th) - [ ] Release CE, EE and CI (#LINK) -Xth: (1 working day after 22th) +Xth: (1 working day after the 22nd) -- [ ] Deploy to GitLab.com (#LINK) +- [ ] Update GitLab.com with the stable version (#LINK) ``` @@ -198,6 +199,6 @@ Proposed tweet "Release of GitLab X.X & CI Y.Y! FEATURE, FEATURE and FEATURE
  • Date: Mon, 12 Jan 2015 22:19:22 -0500 Subject: Updated monthly.md add instructions about the handling of the CHANGELOG Added DISCLAIMER to CHANGELOG --- doc/release/monthly.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 42a7e96ec35..7e2e4f41d6e 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -85,14 +85,26 @@ Stop merging code in master, except for important bug fixes ## Update changelog -Any changes not yet added to the changelog are added by lead developer and in that merge request the complete team is asked if there is anything missing. +Any changes not yet added to the changelog are added by lead developer and in that merge request the complete team is +asked if there is anything missing. There are three changelogs that need to be updated: CE, EE and CI. +Remove the DISCLAIMER text in the stable branches. + ## Create RC1 (CE, EE, CI) [Follow this How-to guide](howto_rc1.md) to create RC1. +## Prepare CHANGELOG for next release + +Once the stable branches have been created, update the CHANGELOG in `master` with the upcoming version and add 70 empty +lines to it. We do this in order to avoid merge conflicts when merging the CHANGELOG. + +Make sure that the CHANGELOG im master contains the following disclaimer message: + +> DISCLAIMER: The upcoming release contains empty lines to reduce the number of merge conflicts, scroll down to see past releases. + ## QA Create issue on dev.gitlab.org `gitlab` repository, named "GitLab X.X QA" in order to keep track of the progress. -- cgit v1.2.1 From e588328674f1c0c956b924c9ec78391d209150cd Mon Sep 17 00:00:00 2001 From: Patricio Cano Date: Mon, 12 Jan 2015 22:26:51 -0500 Subject: Fixed wording in message. --- doc/release/monthly.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 7e2e4f41d6e..175112b90c6 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -90,7 +90,7 @@ asked if there is anything missing. There are three changelogs that need to be updated: CE, EE and CI. -Remove the DISCLAIMER text in the stable branches. +Remove the Note text in the stable branches. ## Create RC1 (CE, EE, CI) @@ -103,7 +103,7 @@ lines to it. We do this in order to avoid merge conflicts when merging the CHANG Make sure that the CHANGELOG im master contains the following disclaimer message: -> DISCLAIMER: The upcoming release contains empty lines to reduce the number of merge conflicts, scroll down to see past releases. +> Note: The upcoming release contains empty lines to reduce the number of merge conflicts, scroll down to see past releases. ## QA -- cgit v1.2.1 From 8e36070cce9ba4b414397674d1f236c33f2689cc Mon Sep 17 00:00:00 2001 From: Dmitriy Zaporozhets Date: Wed, 14 Jan 2015 17:44:59 -0800 Subject: Remove bold text --- doc/release/howto_rc1.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'doc/release') diff --git a/doc/release/howto_rc1.md b/doc/release/howto_rc1.md index 2bfc23951ec..1b55eea5362 100644 --- a/doc/release/howto_rc1.md +++ b/doc/release/howto_rc1.md @@ -2,14 +2,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. -### **1. Update the installation guide** +### 1. Update the installation guide 1. Check if it references the correct branch `x-x-stable` (doesn't exist yet, but that is okay) 1. Check the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782) 1. Check the [Git version](/lib/tasks/gitlab/check.rake#L794) 1. There might be other changes. Ask around. -### **2. Create update guides** +### 2. Create update guides 1. Create: CE update guide from previous version. Like `7.3-to-7.4.md` 1. Create: CE to EE update guide in EE repository for latest version. @@ -65,7 +65,7 @@ Check if the `init.d/gitlab` script changed since last release: [lib/support/ini #### 10. Check application status -### **3. Code quality indicators** +### 3. Code quality indicators Make sure the code quality indicators are green / good. -- cgit v1.2.1 From 41353b63626a4d5eae3570015bfba72748364f35 Mon Sep 17 00:00:00 2001 From: Dmitriy Zaporozhets Date: Thu, 15 Jan 2015 02:07:42 +0000 Subject: Fix code block in rc1 doc --- doc/release/howto_rc1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/release') diff --git a/doc/release/howto_rc1.md b/doc/release/howto_rc1.md index 1b55eea5362..25923d16f34 100644 --- a/doc/release/howto_rc1.md +++ b/doc/release/howto_rc1.md @@ -121,6 +121,6 @@ Add to your local `gitlab-ci/.git/config`: * Create a stable branch `x-y-stable` * Bump VERSION to `x.y.0.rc1` -* `git tag -a v$(cat VERSION) -m "Version $(cat VERSION)" +* `git tag -a v$(cat VERSION) -m "Version $(cat VERSION)"` * `git push public x-y-stable v$(cat VERSION)` -- cgit v1.2.1 From ad6c372eeee5d112ad199dd4e487df584976445d Mon Sep 17 00:00:00 2001 From: Ewan Edwards Date: Tue, 3 Feb 2015 15:18:40 -0800 Subject: Fix a number of discovered typos, capitalization of developer and product names, plus a couple of instances of bad Markdown markup. --- doc/release/howto_rc1.md | 2 +- doc/release/monthly.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'doc/release') diff --git a/doc/release/howto_rc1.md b/doc/release/howto_rc1.md index 25923d16f34..e8e8c8a821d 100644 --- a/doc/release/howto_rc1.md +++ b/doc/release/howto_rc1.md @@ -104,7 +104,7 @@ bundle exec rake release["x.x.0.rc1"] ``` Now developers can use master for merging new features. -So you should use stable branch for future code chages related to release. +So you should use stable branch for future code changes related to release. ### 5. Release GitLab CI RC1 diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 175112b90c6..4297bc7e2b7 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -207,7 +207,7 @@ __3. Tweet to blog__ Send out a tweet to share the good news with the world. List the most important features and link to the blog post. -Proposed tweet "Release of GitLab X.X & CI Y.Y! FEATURE, FEATURE and FEATURE #gitlab" +Proposed tweet "Release of GitLab X.X & CI Y.Y! FEATURE, FEATURE and FEATURE <link-to-blog-post> #gitlab" Consider creating a post on Hacker News. -- cgit v1.2.1 From c93f4662d87058efaec2c2912bd10f8cc5572b3d Mon Sep 17 00:00:00 2001 From: Dmitriy Zaporozhets Date: Mon, 9 Feb 2015 10:30:06 -0800 Subject: Extract update guide to separate doc to prevent mess --- doc/release/howto_rc1.md | 54 +------------------------------------ doc/release/howto_update_guides.md | 55 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+), 53 deletions(-) create mode 100644 doc/release/howto_update_guides.md (limited to 'doc/release') diff --git a/doc/release/howto_rc1.md b/doc/release/howto_rc1.md index e8e8c8a821d..c4156d25d5f 100644 --- a/doc/release/howto_rc1.md +++ b/doc/release/howto_rc1.md @@ -11,59 +11,7 @@ The RC1 release comes with the task to update the installation and upgrade docs. ### 2. Create update guides -1. Create: CE update guide from previous version. Like `7.3-to-7.4.md` -1. Create: CE to EE update guide in EE repository for latest version. -1. Update: `6.x-or-7.x-to-7.x.md` to latest version. -1. Create: CI update guide from previous version - -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. Stop server - -#### 2. Make backup - -#### 3. Do users need to update dependencies like `git`? - -- Check if the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782) changed since the last release. - -- Check if the [Git version](/lib/tasks/gitlab/check.rake#L794) changed since the last release. - -#### 4. Get latest code - -#### 5. Does GitLab shell need to be updated? - -#### 6. Install libs, migrations, etc. - -#### 7. Any config files updated since last release? - -Check if any of these changed since last release: - -- [lib/support/nginx/gitlab](/lib/support/nginx/gitlab) -- [lib/support/nginx/gitlab-ssl](/lib/support/nginx/gitlab-ssl) -- -- [config/gitlab.yml.example](/config/gitlab.yml.example) -- [config/unicorn.rb.example](/config/unicorn.rb.example) -- [config/database.yml.mysql](/config/database.yml.mysql) -- [config/database.yml.postgresql](/config/database.yml.postgresql) -- [config/initializers/rack_attack.rb.example](/config/initializers/rack_attack.rb.example) -- [config/resque.yml.example](/config/resque.yml.example) - -#### 8. Need to update init script? - -Check if the `init.d/gitlab` script changed since last release: [lib/support/init.d/gitlab](/lib/support/init.d/gitlab) - -#### 9. Start application - -#### 10. Check application status +[Follow this guide](howto_update_guides.md) to create update guides. ### 3. Code quality indicators diff --git a/doc/release/howto_update_guides.md b/doc/release/howto_update_guides.md new file mode 100644 index 00000000000..23d0959c33d --- /dev/null +++ b/doc/release/howto_update_guides.md @@ -0,0 +1,55 @@ +# Create update guides + +1. Create: CE update guide from previous version. Like `7.3-to-7.4.md` +1. Create: CE to EE update guide in EE repository for latest version. +1. Update: `6.x-or-7.x-to-7.x.md` to latest version. +1. Create: CI update guide from previous version + +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. Stop server + +#### 2. Make backup + +#### 3. Do users need to update dependencies like `git`? + +- Check if the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782) changed since the last release. + +- Check if the [Git version](/lib/tasks/gitlab/check.rake#L794) changed since the last release. + +#### 4. Get latest code + +#### 5. Does GitLab shell need to be updated? + +#### 6. Install libs, migrations, etc. + +#### 7. Any config files updated since last release? + +Check if any of these changed since last release: + +- [lib/support/nginx/gitlab](/lib/support/nginx/gitlab) +- [lib/support/nginx/gitlab-ssl](/lib/support/nginx/gitlab-ssl) +- +- [config/gitlab.yml.example](/config/gitlab.yml.example) +- [config/unicorn.rb.example](/config/unicorn.rb.example) +- [config/database.yml.mysql](/config/database.yml.mysql) +- [config/database.yml.postgresql](/config/database.yml.postgresql) +- [config/initializers/rack_attack.rb.example](/config/initializers/rack_attack.rb.example) +- [config/resque.yml.example](/config/resque.yml.example) + +#### 8. Need to update init script? + +Check if the `init.d/gitlab` script changed since last release: [lib/support/init.d/gitlab](/lib/support/init.d/gitlab) + +#### 9. Start application + +#### 10. Check application status -- cgit v1.2.1 From 026494029efebd411d597b3cc4c73f59f908012a Mon Sep 17 00:00:00 2001 From: Dmitriy Zaporozhets Date: Mon, 9 Feb 2015 10:32:56 -0800 Subject: Update GitLab.com when packages are done. No need to wait 2 days for it --- doc/release/monthly.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 4297bc7e2b7..12376d36a9a 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -66,15 +66,12 @@ Xth: (1 working day before the 22nd) - [ ] Create CE, EE, CI stable versions (#LINK) - [ ] Create Omnibus tags and build packages +- [ ] Update GitLab.com with the stable version (#LINK) 22nd: - [ ] Release CE, EE and CI (#LINK) -Xth: (1 working day after the 22nd) - -- [ ] Update GitLab.com with the stable version (#LINK) - ``` - - - -- cgit v1.2.1 From 43890ed1dc0d6b4b3cf29116391f52246b4f6eae Mon Sep 17 00:00:00 2001 From: Dmitriy Zaporozhets Date: Mon, 9 Feb 2015 10:46:38 -0800 Subject: Update patch release document --- doc/release/patch.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'doc/release') diff --git a/doc/release/patch.md b/doc/release/patch.md index 2bd34b7d822..d8bb4aef0e2 100644 --- a/doc/release/patch.md +++ b/doc/release/patch.md @@ -18,12 +18,13 @@ Otherwise include it in the monthly release and note there was a regression fix 1. Name the issue "Release X.X.X CE and X.X.X EE", this will make searching easier 1. Fix the issue on a feature branch, do this on the private GitLab development server 1. If it is a security issue, then assign it to the release manager and apply a 'security' label -1. Build the package for GitLab.com and do a deploy 1. Consider creating and testing workarounds 1. After the branch is merged into master, cherry pick the commit(s) into the current stable branch 1. Make sure that the build has passed and all tests are passing -1. In a separate commit in the stable branch update the CHANGELOG +1. In a separate commit in the master branch update the CHANGELOG 1. For EE, update the CHANGELOG-EE if it is EE specific fix. Otherwise, merge the stable CE branch and add to CHANGELOG-EE "Merge community edition changes for version X.X.X" +1. Merge CE stable branch into EE stable branch + ### Bump version @@ -48,9 +49,8 @@ CE=false be rake release['x.x.x'] ### Release -1. Apply the patch to GitLab Cloud and the private GitLab development server 1. [Build new packages with the latest version](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/release.md) -1. Cherry-pick the changelog update back into master +1. Apply the patch to GitLab.com and the private GitLab development server 1. Create and publish a blog post -1. Send tweets about the release from `@gitlabhq`, tweet should include the most important feature that the release is addressing and link to the blog post +1. Send tweets about the release from `@gitlab`, tweet should include the most important feature that the release is addressing and link to the blog post 1. Note in the 'GitLab X.X regressions' issue that the patch was published (CE only) -- cgit v1.2.1 From 4377ba1c360cf6f4d15e3b5ad2a7ed7bc41f795e Mon Sep 17 00:00:00 2001 From: Douwe Maan Date: Thu, 12 Feb 2015 20:34:34 +0100 Subject: Use gitattribute merge=union to reduce CHANGELOG merge conflicts. --- doc/release/monthly.md | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) (limited to 'doc/release') diff --git a/doc/release/monthly.md b/doc/release/monthly.md index 12376d36a9a..c9e6d3426bc 100644 --- a/doc/release/monthly.md +++ b/doc/release/monthly.md @@ -87,20 +87,13 @@ asked if there is anything missing. There are three changelogs that need to be updated: CE, EE and CI. -Remove the Note text in the stable branches. - ## Create RC1 (CE, EE, CI) [Follow this How-to guide](howto_rc1.md) to create RC1. ## Prepare CHANGELOG for next release -Once the stable branches have been created, update the CHANGELOG in `master` with the upcoming version and add 70 empty -lines to it. We do this in order to avoid merge conflicts when merging the CHANGELOG. - -Make sure that the CHANGELOG im master contains the following disclaimer message: - -> Note: The upcoming release contains empty lines to reduce the number of merge conflicts, scroll down to see past releases. +Once the stable branches have been created, update the CHANGELOG in `master` with the upcoming version. ## QA -- cgit v1.2.1