@@ -239,17 +239,26 @@ Note: Merge CE into EE if needed.
- 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.
- Change the VERSION file in `master` branch of the EE repository and commit and push.
- 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.
### **2. Push latest changes from x-x-stable branch to the repositories**
### **2. Update installation.md**
Update [installation.md](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md) to the newest version in master.
### **3. Push latest changes from x-x-stable branch to dev.gitlab.org**
```
git checkout -b x-x-stable
git push <remote> x-x-stable
git push origin x-x-stable
```
### **3. Create annotated tag vx.x.x**
### **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,
...
...
@@ -259,18 +268,7 @@ git tag -a vx.x.0 -m 'Version x.x.0' xxxxx
where `xxxxx` is SHA-1.
### **4. Push the tag**
```
git push origin vx.x.0
```
### **5. 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.
### **6. Push to remotes**
### **6. Push the tag and x-x-stable branch to the remotes**
For GitLab CE, push to dev, GitLab.com and GitHub.
...
...
@@ -278,29 +276,37 @@ For GitLab EE, push to the subscribers repo.
Make sure the branch is marked 'protected' on each of the remotes you pushed to.
### **7. Publish blog for new release**
```
git push <remote> x-x-stable(-ee)
git push <remote> vx.x.0
```
### **7. 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**
Merge the [blog merge request](#1-prepare-the-blog-post) in `www-gitlab-com` repository.
### **8. Tweet to blog**
### **9. 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.
Proposed tweet for CE "GitLab X.X is released! It brings ***<link-to-blogpost>"
### **9. Send out the newsletter**
### **10. Send out the newsletter**
Send out an email to the 'GitLab Newsletter' mailing list on MailChimp.
Replicate the former release newsletter and modify it accordingly.
**Do not forget to edit `Subject line` and regenerate `Plain-Text Email` from HTML source**
Include a link to the blog post and keep it short.
Proposed email text:
"We have released a new version of GitLab. See our blog post(<link>) for more information."
### **10. Update installation.md**
Update [installation.md](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md) to the newest version in master and cherry-pick that commit into the stable branch.
