Skip to content

Commit

Permalink
Use release tool for monthly releases
Browse files Browse the repository at this point in the history
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
  • Loading branch information
dzaporozhets committed Nov 11, 2014
1 parent c6bc57c commit 07cca8c
Showing 1 changed file with 22 additions and 62 deletions.
84 changes: 22 additions & 62 deletions doc/release/monthly.md
Expand Up @@ -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 <remote> x-x-stable
bundle exec rake release["x.x.0.rc1"]
```

Now developers can use master for merging new features.
Expand Down Expand Up @@ -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 <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.

### **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.
Expand Down

0 comments on commit 07cca8c

Please sign in to comment.