@@ -200,7 +200,7 @@ Add to your local `gitlab-ci/.git/config`:
# **4 workdays before release - Release RC1**
### **1. Determine QA person
### **1. Determine QA person**
Notify person of QA day.
...
...
@@ -215,6 +215,7 @@ It is important to do this as soon as possible, so we can catch any errors befor
### **3. Prepare the blog post**
- Start with a complete copy of the [release blog template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/release_blog_template.md) and fill it out.
- Make sure the blog post contains information about the GitLab CI release.
- Check the changelog of CE and EE for important changes.
- Also check the CI changelog
- Add a proposed tweet text to the blog post WIP MR description.
...
...
@@ -269,7 +270,7 @@ Create an issue with description of a problem, if it is quick fix fix it yoursel
**NOTE** If there is a problem that cannot be fixed in a timely manner, reverting the feature is an option! If the feature is reverted,
create an issue about it in order to discuss the next steps after the release.
# **22nd - Release CE, EE and CI**
# **Workday before release - Create Omnibus tags and build packages**
**Make sure EE `x-x-stable-ee` has latest changes from CE `x-x-stable`**
...
...
@@ -306,15 +307,17 @@ Follow the [release doc in the Omnibus repository](https://gitlab.com/gitlab-org
This can happen before tagging because Omnibus uses tags in its own repo and SHA1's to refer to the GitLab codebase.
### **4. Publish packages for new release**
# **22nd - Release CE, EE and CI**
### **1. Publish packages for new release**
Update `downloads/index.html` and `downloads/archive/index.html` in `www-gitlab-com` repository.
### **5. Publish blog for new release**
### **2. Publish blog for new release**
Merge the [blog merge request](#1-prepare-the-blog-post) in `www-gitlab-com` repository.
### **6. Tweet to blog**
### **3. 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.
