2014-04-10 05:23:44 -04:00
# Things to do when doing a patch release
2014-05-27 08:12:15 -04:00
2014-04-10 05:23:44 -04:00
NOTE: This is a guide for GitLab developers. If you are trying to install GitLab see the latest stable [installation guide ](install/installation.md ) and if you are trying to upgrade, see the [upgrade guides ](update ).
## When to do a patch release
2014-04-24 18:48:22 -04:00
Do a patch release when there is a critical regression that needs to be addresses before the next monthly release.
2014-04-10 05:23:44 -04:00
Otherwise include it in the monthly release and note there was a regression fix in the release announcement.
## Release Procedure
2014-11-11 05:01:47 -05:00
### Preparation
2014-04-24 18:48:22 -04:00
1. Verify that the issue can be reproduced
2014-05-27 08:56:52 -04:00
1. Note in the 'GitLab X.X regressions' that you will create a patch
2014-04-10 05:23:44 -04:00
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
2014-11-24 06:14:19 -05:00
1. If it is a security issue, then assign it to the release manager and apply a 'security' label
2014-04-14 03:06:42 -04:00
1. Consider creating and testing workarounds
2014-04-10 05:23:44 -04:00
1. After the branch is merged into master, cherry pick the commit(s) into the current stable branch
2014-11-11 05:01:47 -05:00
1. Make sure that the build has passed and all tests are passing
2015-02-09 13:46:38 -05:00
1. In a separate commit in the master branch update the CHANGELOG
2014-04-10 05:28:12 -04:00
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"
2015-02-09 13:46:38 -05:00
1. Merge CE stable branch into EE stable branch
2014-11-11 05:01:47 -05:00
2014-12-05 06:34:18 -05:00
### Bump version
2014-11-11 05:01:47 -05:00
Get release tools
```
git clone git@dev.gitlab.org:gitlab/release-tools.git
cd release-tools
```
2015-04-07 16:24:15 -04:00
Bump all versions in stable branch, even if the changes affect only EE, CE, or CI. Since all the versions are synced now,
it doesn't make sense to say upgrade CE to 7.2, EE to 7.3 and CI to 7.1.
2014-11-11 05:01:47 -05:00
2015-04-07 16:24:15 -04:00
Create release tag and push to remotes:
2014-11-11 05:01:47 -05:00
```
2015-04-07 16:24:15 -04:00
bundle exec rake release["x.x.x"]
2014-11-11 05:01:47 -05:00
```
2015-05-07 10:26:21 -04:00
## Release
2014-11-11 05:01:47 -05:00
2014-06-04 03:27:23 -04:00
1. [Build new packages with the latest version ](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/release.md )
2015-02-09 13:46:38 -05:00
1. Apply the patch to GitLab.com and the private GitLab development server
2015-03-12 00:11:32 -04:00
1. Apply the patch to ci.gitLab.com and the private GitLab CI development server
2015-02-27 13:38:15 -05:00
1. Create and publish a blog post, see [patch release blog template ](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/patch_release_blog_template.md )
2015-02-09 13:46:38 -05:00
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
2014-07-21 04:47:38 -04:00
1. Note in the 'GitLab X.X regressions' issue that the patch was published (CE only)
2015-08-05 07:11:25 -04:00
1. Create the 'x.y.0' version on version.gitlab.com
2015-03-11 12:31:39 -04:00
1. [Create new AMIs ](https://dev.gitlab.org/gitlab/AMI/blob/master/README.md )
2015-05-07 10:26:21 -04:00
1. Create a new patch release issue for the next potential release