Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
G
gitlab-ce
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Jérome Perrin
gitlab-ce
Commits
07cca8cc
Commit
07cca8cc
authored
Nov 11, 2014
by
Dmitriy Zaporozhets
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Use release tool for monthly releases
Signed-off-by:
Dmitriy Zaporozhets
<
dmitriy.zaporozhets@gmail.com
>
parent
c6bc57c1
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
22 additions
and
62 deletions
+22
-62
doc/release/monthly.md
doc/release/monthly.md
+22
-62
No files found.
doc/release/monthly.md
View file @
07cca8cc
...
...
@@ -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.
...
...
@@ -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 c
heckout -b x-x-stable
git push origin x-x-stable
git c
lone 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.
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment