Update release instructions in light of new tasks.

1 files changed, 46 insertions, 44 deletions

diff --git a/RELEASING_RAILS.md b/RELEASING_RAILS.md
index 6e27d8ee5a..3ff28c29f5 100644
--- a/RELEASING_RAILS.md
+++ b/RELEASING_RAILS.md
@@ -1,35 +1,35 @@
 # Releasing Rails
 
-In this document, we'll cover the steps necessary to release Rails.  Each
-section contains steps to take during that time before the release.  The times
-suggested in each header are just that: suggestions.  However, they should
+In this document, we'll cover the steps necessary to release Rails. Each
+section contains steps to take during that time before the release. The times
+suggested in each header are just that: suggestions. However, they should
 really be considered as minimums.
 
 ## 10 Days before release
 
-Today is mostly coordination tasks.  Here are the things you must do today:
+Today is mostly coordination tasks. Here are the things you must do today:
 
-### Is the CI green?  If not, make it green. (See "Fixing the CI")
+### Is the CI green? If not, make it green. (See "Fixing the CI")
 
-Do not release with a Red CI.  You can find the CI status here:
+Do not release with a Red CI. You can find the CI status here:
 
 ```
 http://travis-ci.org/rails/rails
 ```
 
-### Is Sam Ruby happy?  If not, make him happy.
+### Is Sam Ruby happy? If not, make him happy.
 
 Sam Ruby keeps a [test suite](https://github.com/rubys/awdwr) that makes
 sure the code samples in his book
 ([Agile Web Development with Rails](https://pragprog.com/titles/rails5/agile-web-development-with-rails-5th-edition))
-all work.  These are valuable system tests
-for Rails.  You can check the status of these tests here:
+all work. These are valuable system tests
+for Rails. You can check the status of these tests here:
 
 [http://intertwingly.net/projects/dashboard.html](http://intertwingly.net/projects/dashboard.html)
 
 Do not release with Red AWDwR tests.
 
-### Do we have any Git dependencies?  If so, contact those authors.
+### Do we have any Git dependencies? If so, contact those authors.
 
 Having Git dependencies indicates that we depend on unreleased code.
 Obviously Rails cannot be released when it depends on unreleased code.
@@ -38,12 +38,12 @@ suits them.
 
 ### Contact the security team (either tenderlove or rafaelfranca)
 
-Let them know of your plans to release.  There may be security issues to be
+Let them know of your plans to release. There may be security issues to be
 addressed, and that can impact your release date.
 
 ### Notify implementors.
 
-Ruby implementors have high stakes in making sure Rails works.  Be kind and
+Ruby implementors have high stakes in making sure Rails works. Be kind and
 give them a heads up that Rails will be released soonish.
 
 This is only required for major and minor releases, bugfix releases aren't a
@@ -60,18 +60,18 @@ Implementors will love you and help you.
 
 ## 3 Days before release
 
-This is when you should release the release candidate.  Here are your tasks
+This is when you should release the release candidate. Here are your tasks
 for today:
 
-### Is the CI green?  If not, make it green.
+### Is the CI green? If not, make it green.
 
-### Is Sam Ruby happy?  If not, make him happy.
+### Is Sam Ruby happy? If not, make him happy.
 
-### Contact the security team.  CVE emails must be sent on this day.
+### Contact the security team. CVE emails must be sent on this day.
 
 ### Create a release branch.
 
-From the stable branch, create a release branch.  For example, if you're
+From the stable branch, create a release branch. For example, if you're
 releasing Rails 3.0.10, do this:
 
 ```
@@ -82,7 +82,7 @@ Switched to a new branch '3-0-10'
 
 ### Update each CHANGELOG.
 
-Many times commits are made without the CHANGELOG being updated.  You should
+Many times commits are made without the CHANGELOG being updated. You should
 review the commits since the last release, and fill in any missing information
 for each CHANGELOG.
 
@@ -96,15 +96,15 @@ If you're doing a stable branch release, you should also ensure that all of
 the CHANGELOG entries in the stable branch are also synced to the master
 branch.
 
-### Update the RAILS_VERSION file to include the RC.
+### Put the new version in the RAILS_VERSION file.
 
-### Build and test the gem.
+Include an RC number if appropriate, e.g. `6.0.0.rc1`.
 
-Run `rake install` to generate the gems and install them locally. Then try
-generating a new app and ensure that nothing explodes.
+### Build and test the gem.
 
-Verify that Action Cable and Action View's package.json files are updated with
-the RC version.
+Run `rake verify` to generate the gems and install them locally. `verify` also
+generates a Rails app with a migration and boots it to smoke test with in your
+browser.
 
 This will stop you from looking silly when you push an RC to rubygems.org and
 then realize it is broken.
@@ -117,37 +117,39 @@ as NPM packages, so you must have Node.js installed, have an NPM account
 check this via `npm owner ls actioncable` and `npm owner ls rails-ujs`) in
 order to do a full release. Do not release until you're set up with NPM!
 
+The release task will sign the release tag. If you haven't got commit signing
+set up, use https://git-scm.com/book/tr/v2/Git-Tools-Signing-Your-Work as a
+guide. You can generate keys with the GPG suite from here: https://gpgtools.org.
+
+Run `rake changelog:header` to put a header with the new version in every
+CHANGELOG. Don't commit this, the release task handles it.
+
 Run `rake release`. This will populate the gemspecs and NPM package.json with
 the current RAILS_VERSION, commit the changes, tag it, and push the gems to
 rubygems.org.
 
-Here are the commands that `rake release` uses so you can understand what to do
-in case anything goes wrong:
-
-```
-$ rake all:build
-$ git commit -am'updating RAILS_VERSION'
-$ git tag -m 'v3.0.10.rc1 release' v3.0.10.rc1
-$ git push
-$ git push --tags
-$ for i in $(ls pkg); do gem push $i; npm publish; done
-```
-
 ### Send Rails release announcements
 
 Write a release announcement that includes the version, changes, and links to
-GitHub where people can find the specific commit list.  Here are the mailing
+GitHub where people can find the specific commit list. Here are the mailing
 lists where you should announce:
 
 * rubyonrails-core@googlegroups.com
 * rubyonrails-talk@googlegroups.com
 * ruby-talk@ruby-lang.org
 
-Use Markdown format for your announcement.  Remember to ask people to report
+Use Markdown format for your announcement. Remember to ask people to report
 issues with the release candidate to the rails-core mailing list.
 
+NOTE: For patch releases there's a `rake announce` task to generate the release
+post. It supports multiple patch releases too:
+
+```
+VERSIONS="5.0.5.rc1,5.1.3.rc1" rake announce
+```
+
 IMPORTANT: If any users experience regressions when using the release
-candidate, you *must* postpone the release.  Bugfix releases *should not*
+candidate, you *must* postpone the release. Bugfix releases *should not*
 break existing applications.
 
 ### Post the announcement to the Rails blog.
@@ -165,12 +167,12 @@ Check the rails-core mailing list and the GitHub issue list for regressions in
 the RC.
 
 If any regressions are found, fix the regressions and repeat the release
-candidate process.  We will not release the final until 72 hours after the
-last release candidate has been pushed.  This means that if users find
+candidate process. We will not release the final until 72 hours after the
+last release candidate has been pushed. This means that if users find
 regressions, the scheduled release date must be postponed.
 
-When you fix the regressions, do not create a new branch.  Fix them on the
-stable branch, then cherry pick the commit to your release branch.  No other
+When you fix the regressions, do not create a new branch. Fix them on the
+stable branch, then cherry pick the commit to your release branch. No other
 commits should be added to the release branch besides regression fixing commits.
 
 ## Day of release
@@ -203,7 +205,7 @@ Email the security reports to:
 * oss-security@lists.openwall.com
 
 Be sure to note the security fixes in your announcement along with CVE numbers
-and links to each patch.  Some people may not be able to upgrade right away,
+and links to each patch. Some people may not be able to upgrade right away,
 so we need to give them the security fixes in patch form.
 
 * Blog announcements