# Things to do when creating new monthly minor or major release
# Monthly Release
NOTE: This is a guide for GitLab developers. If you are trying to install GitLab see the latest stable [installation guide](install/installation.md) and if you are trying to upgrade, see the [upgrade guides](update).
After making the release branch new commits are cherry-picked from master. When the release gets closer we get more selective what is cherry-picked. The days of the month are approximately as follows:
* 1-7th: Official merge window (see contributing guide).
* 8-14th: Work on bugfixes, sponsored features and GitLab EE.
* 15th: Code freeze
* 18th: Release Candidate 1
* 20st: Optional release candidate 2
* 22nd: Release
* 23nd: Optional patch releases
* 24-end of month: Release GitLab EE and GitLab CI
# 15th - Code Freeze & Release Manager
- Stop merging in code, except for important bugfixes
## 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.
# 18th - Releasing RC1
> Yo dawg, I heard you like releases..
The RC1 release comes with the task to update the installation and upgrade docs. Be mindful that there might already be merge requests for this on GitLab or GitHub.
### 1. Create an issue for RC1 release
### 2. Update the installation guide
1. Check if it references the correct branch `x-x-stable` (doesn't exist yet, but that is okay)
2. Check the [GitLab Shell version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L782)
3. Check the [Git version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L794)
4. There might be other changes. Ask around.
## Make upgrade guide
### 3. Create an update guide
### From x.x to x.x
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? Database updates? Web server change? File structure changes?
#### 0. Any major changes?
List any major changes here, so the user is aware of them before starting to upgrade. For instance:
- Database updates
- Web server changes
- File structure changes
#### 1. Make backup
...
...
@@ -17,9 +53,9 @@ NOTE: This is a guide for GitLab developers. If you are trying to install GitLab
#### 3. Do users need to update dependencies like `git`?
- Check the [GitLab Shell version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L782)
- Check if the [GitLab Shell version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L782) changed since the last release.
- Check the [Git version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L794)
- Check if the [Git version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L794) changed since the last release.
#### 4. Get latest code
...
...
@@ -29,7 +65,7 @@ NOTE: This is a guide for GitLab developers. If you are trying to install GitLab
#### 7. Any config files updated since last release?
Check if any of these changed since last release (~22nd of last month depending on when last release branch was created):
@@ -40,13 +76,14 @@ Check if any of these changed since last release (~22nd of last month depending
#### 8. Need to update init script?
Check if changed since last release (~22nd of last month depending on when last release branch was created): https://gitlab.com/gitlab-org/gitlab-ce/commits/master/lib/support/init.d/gitlab
Check if the init.d/gitlab script changed since last release: https://gitlab.com/gitlab-org/gitlab-ce/commits/master/lib/support/init.d/gitlab
#### 9. Start application
#### 10. Check application status
## Make sure the code quality indicatiors are good
### 4. Code quality indicatiors
Make sure the code quality indicators are green / good.
*[](http://ci.gitlab.org/projects/1?ref=master) on ci.gitlab.org (master branch)
...
...
@@ -58,34 +95,42 @@ Check if changed since last release (~22nd of last month depending on when last
Create an annotated tag that points to the version change commit.
```
git tag -a vx.x.0.rc1 -m 'Version x.x.0.rc1'
```
### 7. Tweet
Tweet about the RC release. Make sure to explain what a RC is.
### 8. Update Cloud
Merge the RC1 code into Cloud. Once the build is green, deploy in the morning.
It is important to do this as soon as possible, so we can catch any errors before we release the full version.
# 22nd - Release
After making the release branch new commits are cherry-picked from master. When the release gets closer we get more selective what is cherry-picked. The days of the month are approximately as follows:
* 1-7th: Official merge window (see contributing guide).
* 8-14th: Work on bugfixes, sponsored features and GitLab EE.
* 15th: Code freeze
- Stop merging into master, except essential bugfixes
- Select a Release Manager
* 18th: Release Candidate 1
- Set VERSION to x.x.0.rc1
- Create annotated tag x.x.0.rc1
- Push the changes to GitLab.com, dev.gitlab.com, GitHub
- Tweet about the release
- Create a new branch on cloud for rc1
- Deploy the new branch on Cloud after tests pass
* 20st: Optional release candidate 2 (x.x.0.rc2, only if rc1 had problems)
* 22nd: Release
- Create x-x-stable branch and push to the repositories
- QA
- Fix anything coming out of the QA
- Set VERSION to x.x.0
- Create annotated tag x.x.0
- Push VERSION + Tag to master, merge into x-x-stable
- Publish blog for new release
- Tweet to blog (see below)
* 23nd: optional patch releases (x.x.1, x.x.2, etc., only if there are serious problems)
* 24-end of month: release GitLab EE and GitLab CI
- Create x-x-stable branch and push to the repositories
- QA
- Fix anything coming out of the QA
- Set VERSION to x.x.0
- Create annotated tag x.x.0
- Push VERSION + Tag to master, merge into x-x-stable
