Commit 8dc9cb3d authored by Dmitriy Zaporozhets's avatar Dmitriy Zaporozhets

Merge branch 'doc-release-tools' into 'master'

Update release documentation to use release tools

See merge request !1245
parents 1aa34f14 a15dc7b8
No related merge requests found
...@@ -143,35 +143,21 @@ Make sure the code quality indicators are green / good. ...@@ -143,35 +143,21 @@ 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) - [![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`. **Make sure EE `master` has latest changes from CE `master`**
### **5. Tag** Get release tools
Create an annotated tag that points to the version change commit:
```
git tag -a vx.x.0.rc1 -m 'Version x.x.0.rc1'
``` ```
git clone git@dev.gitlab.org:gitlab/release-tools.git
Tags should be created for both GitLab CE and GitLab EE. Don't forget to push tags to all remotes. cd release-tools
``` ```
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 bundle exec rake release["x.x.0.rc1"]
git pull
git checkout -b x-x-stable
git push <remote> x-x-stable
``` ```
Now developers can use master for merging new features. Now developers can use master for merging new features.
...@@ -245,69 +231,45 @@ create an issue about it in order to discuss the next steps after the release. ...@@ -245,69 +231,45 @@ create an issue about it in order to discuss the next steps after the release.
# **22nd - Release CE and EE** # **22nd - Release CE and EE**
For GitLab EE, append `-ee` to the branches and tags. **Make sure EE `x-x-stable-ee` has latest changes from CE `x-x-stable`**
`x-x-stable-ee`
`v.x.x.0-ee`
Note: Merge CE into EE if needed.
### **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.
### **2. Update installation.md**
Update [installation.md](/doc/install/installation.md) to the newest version in master. ### **1. Release code**
### **3. Push latest changes from x-x-stable branch to dev.gitlab.org** Get release tools
``` ```
git checkout -b x-x-stable git clone git@dev.gitlab.org:gitlab/release-tools.git
git push origin x-x-stable cd release-tools
``` ```
### **4. Build the Omnibus packages** Bump version, create release tag and push to remotes:
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,
``` ```
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 <remote> x-x-stable(-ee)
git push <remote> 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. 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. 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. Send out a tweet to share the good news with the world.
List the most important features and link to the blog post. List the most important features and link to the blog post.
......
...@@ -10,6 +10,8 @@ Otherwise include it in the monthly release and note there was a regression fix ...@@ -10,6 +10,8 @@ Otherwise include it in the monthly release and note there was a regression fix
## Release Procedure ## Release Procedure
### Preparation
1. Verify that the issue can be reproduced 1. Verify that the issue can be reproduced
1. Note in the 'GitLab X.X regressions' that you will create a patch 1. Note in the 'GitLab X.X regressions' that you will create a patch
1. Create an issue on private GitLab development server 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 ...@@ -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. Fix the issue on a feature branch, do this on the private GitLab development server
1. Consider creating and testing workarounds 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. 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 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. 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'` ### Bump version
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 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. 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. [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. Cherry-pick the changelog update back into master
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment