aboutsummaryrefslogtreecommitdiffstats
path: root/RELEASING_RAILS.md
diff options
context:
space:
mode:
Diffstat (limited to 'RELEASING_RAILS.md')
-rw-r--r--RELEASING_RAILS.md90
1 files changed, 46 insertions, 44 deletions
diff --git a/RELEASING_RAILS.md b/RELEASING_RAILS.md
index 6e27d8ee5a..c61fe7eb13 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