More updates to release doc.

doc/release/monthly.md

@@ -165,7 +165,7 @@ git checkout -b x-x-stable
 git push <remote> x-x-stable
 ```
 
-Now developers can use master for merging new features. 
+Now developers can use master for merging new features.
 So you should use stable branch for future code chages related to release.
 
 
@@ -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.
 
 # **23rd - Optional Patch Release**