Merge branch 'improve-release-guides' into 'master'

doc/release/howto_rc1.md

@@ -11,59 +11,7 @@ The RC1 release comes with the task to update the installation and upgrade docs.
 
 ### 2. Create update guides
 
-1. Create: CE update guide from previous version. Like `7.3-to-7.4.md`
-1. Create: CE to EE update guide in EE repository for latest version.
-1. Update: `6.x-or-7.x-to-7.x.md` to latest version.
-1. Create: CI update guide from previous version
-
-It's best to copy paste the previous guide and make changes where necessary.
-The typical steps are listed below with any points you should specifically look at.
-
-#### 0. Any major changes?
-
-List any major changes here, so the user is aware of them before starting to upgrade. For instance:
-
-- Database updates
-- Web server changes
-- File structure changes
-
-#### 1. Stop server
-
-#### 2. Make backup
-
-#### 3. Do users need to update dependencies like `git`?
-
-- Check if the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782) changed since the last release.
-
-- Check if the [Git version](/lib/tasks/gitlab/check.rake#L794) changed since the last release.
-
-#### 4. Get latest code
-
-#### 5. Does GitLab shell need to be updated?
-
-#### 6. Install libs, migrations, etc.
-
-#### 7. Any config files updated since last release?
-
-Check if any of these changed since last release:
-
-- [lib/support/nginx/gitlab](/lib/support/nginx/gitlab)
-- [lib/support/nginx/gitlab-ssl](/lib/support/nginx/gitlab-ssl)
-- <https://gitlab.com/gitlab-org/gitlab-shell/commits/master/config.yml.example>
-- [config/gitlab.yml.example](/config/gitlab.yml.example)
-- [config/unicorn.rb.example](/config/unicorn.rb.example)
-- [config/database.yml.mysql](/config/database.yml.mysql)
-- [config/database.yml.postgresql](/config/database.yml.postgresql)
-- [config/initializers/rack_attack.rb.example](/config/initializers/rack_attack.rb.example)
-- [config/resque.yml.example](/config/resque.yml.example)
-
-#### 8. Need to update init script?
-
-Check if the `init.d/gitlab` script changed since last release: [lib/support/init.d/gitlab](/lib/support/init.d/gitlab)
-
-#### 9. Start application
-
-#### 10. Check application status
+[Follow this guide](howto_update_guides.md) to create update guides.
 
 ### 3. Code quality indicators
 

doc/release/howto_update_guides.md

+# Create update guides
+
+1. Create: CE update guide from previous version. Like `7.3-to-7.4.md`
+1. Create: CE to EE update guide in EE repository for latest version.
+1. Update: `6.x-or-7.x-to-7.x.md` to latest version.
+1. Create: CI update guide from previous version
+
+It's best to copy paste the previous guide and make changes where necessary.
+The typical steps are listed below with any points you should specifically look at.
+
+#### 0. Any major changes?
+
+List any major changes here, so the user is aware of them before starting to upgrade. For instance:
+
+- Database updates
+- Web server changes
+- File structure changes
+
+#### 1. Stop server
+
+#### 2. Make backup
+
+#### 3. Do users need to update dependencies like `git`?
+
+- Check if the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782) changed since the last release.
+
+- Check if the [Git version](/lib/tasks/gitlab/check.rake#L794) changed since the last release.
+
+#### 4. Get latest code
+
+#### 5. Does GitLab shell need to be updated?
+
+#### 6. Install libs, migrations, etc.
+
+#### 7. Any config files updated since last release?
+
+Check if any of these changed since last release:
+
+- [lib/support/nginx/gitlab](/lib/support/nginx/gitlab)
+- [lib/support/nginx/gitlab-ssl](/lib/support/nginx/gitlab-ssl)
+- <https://gitlab.com/gitlab-org/gitlab-shell/commits/master/config.yml.example>
+- [config/gitlab.yml.example](/config/gitlab.yml.example)
+- [config/unicorn.rb.example](/config/unicorn.rb.example)
+- [config/database.yml.mysql](/config/database.yml.mysql)
+- [config/database.yml.postgresql](/config/database.yml.postgresql)
+- [config/initializers/rack_attack.rb.example](/config/initializers/rack_attack.rb.example)
+- [config/resque.yml.example](/config/resque.yml.example)
+
+#### 8. Need to update init script?
+
+Check if the `init.d/gitlab` script changed since last release: [lib/support/init.d/gitlab](/lib/support/init.d/gitlab)
+
+#### 9. Start application
+
+#### 10. Check application status

doc/release/monthly.md

@@ -66,15 +66,12 @@ Xth: (1 working day before the 22nd)
 
 - [ ] Create CE, EE, CI stable versions (#LINK)
 - [ ] Create Omnibus tags and build packages
+- [ ] Update GitLab.com with the stable version (#LINK)
 
 22nd:
 
 - [ ] Release CE, EE and CI (#LINK)
 
-Xth: (1 working day after the 22nd)
-
-- [ ] Update GitLab.com with the stable version (#LINK)
-
 ```
 
 - - -

doc/release/patch.md

@@ -18,12 +18,13 @@ Otherwise include it in the monthly release and note there was a regression fix
 1. Name the issue "Release X.X.X CE and X.X.X EE", this will make searching easier
 1. Fix the issue on a feature branch, do this on the private GitLab development server
 1. If it is a security issue, then assign it to the release manager and apply a 'security' label
-1. Build the package for GitLab.com and do a deploy
 1. Consider creating and testing workarounds
 1. After the branch is merged into master, cherry pick the commit(s) into the current stable branch
 1. Make sure that the build has passed and all tests are passing
-1. In a separate commit in the stable branch update the CHANGELOG
+1. In a separate commit in the master branch update the CHANGELOG
 1. For EE, update the CHANGELOG-EE if it is EE specific fix. Otherwise, merge the stable CE branch and add to CHANGELOG-EE "Merge community edition changes for version X.X.X"
+1. Merge CE stable branch into EE stable branch
+
 
 ### Bump version
 
@@ -48,9 +49,8 @@ CE=false be rake release['x.x.x']
 
 ### Release
 
-1. Apply the patch to GitLab Cloud and the private GitLab development server
 1. [Build new packages with the latest version](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/release.md)
-1. Cherry-pick the changelog update back into master
+1. Apply the patch to GitLab.com and the private GitLab development server
 1. Create and publish a blog post
-1. Send tweets about the release from `@gitlabhq`, tweet should include the most important feature that the release is addressing and link to the blog post
+1. Send tweets about the release from `@gitlab`, tweet should include the most important feature that the release is addressing and link to the blog post
 1. Note in the 'GitLab X.X regressions' issue that the patch was published (CE only)