Things to do when doing a patch release

NOTE: This is a guide for GitLab developers. If you are trying to install GitLab see the latest stable installation guide and if you are trying to upgrade, see the upgrade guides.

When to do a patch release

Patch releases are done as-needed in order to fix regressions in the current major release that cannot or should not wait until the next major release. What's included and when to release is at the discretion of the release manager.

Release Procedure

Create a patch issue

Create an issue in the GitLab CE project. Name it "Release x.y.z", tag it with the release label, and assign it to the milestone of the corresponding major release.

Use the following template:

- Picked into respective `stable` branches:
- [ ] Merge `x-y-stable` into `x-y-stable-ee`
- [ ] release-tools: `x.y.z`
- omnibus-gitlab
  - [ ] `x.y.z+ee.0`
  - [ ] `x.y.z+ce.0`
- [ ] Deploy
- [ ] Add patch notice to [x.y regressions]()
- [ ] [Blog post]()
- [ ] [Tweet]()
- [ ] Add entry to version.gitlab.com

Update the issue with links to merge requests that need to be/have been picked into the stable branches.

Preparation

Verify that the issue can be reproduced
Note in the 'GitLab X.X regressions' that you will create a patch
Fix the issue on a feature branch, do this on the private GitLab development server
If it is a security issue, then assign it to the release manager and apply a 'security' label
Consider creating and testing workarounds
After the branch is merged into master, cherry pick the commit(s) into the current stable branch
Make sure that the build has passed and all tests are passing
In a separate commit in the master branch update the CHANGELOG
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"
Merge CE stable branch into EE stable branch

Bump version

Get release tools

git clone git@dev.gitlab.org:gitlab/release-tools.git
cd release-tools

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.

Create release tag and push to remotes:

bundle exec rake release["x.x.x"]

Release

Build new packages with the latest version
Apply the patch to GitLab.com and the private GitLab development server
Apply the patch to ci.gitLab.com and the private GitLab CI development server
Create and publish a blog post, see patch release blog template
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
Note in the 'GitLab X.X regressions' issue that the patch was published (CE only)
Create the 'x.y.0' version on version.gitlab.com
Create new AMIs
Create a new patch release issue for the next potential release

3.2 KiB Raw Blame History