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.
Today is mostly coordination tasks. Here are the things you must do today:
Do not release with a Red CI. You can find the CI status here:
Sam Ruby keeps a test suite that makes sure the code samples in his book (Agile Web Development with Rails) all work. These are valuable integration tests for Rails. You can check the status of his tests here:
Do not release with Red AWDwR tests.
Having git dependencies indicates that we depend on unreleased code. Obviously rails cannot be released when it depends on unreleased code. Contact the authors of those particular gems and work out a release date that suites them.
Let them know of your plans to release. There may be security issues to be addressed, and that can impact your release date.
Ruby implementors have high stakes in making sure Rails works. Be kind and give them a heads up that Rails will be released soonish.
Send an email just giving a heads up about the upcoming release to these lists:
Implementors will love you and help you.
This is when you should release the release candidate. Here are your tasks for today:
From the stable branch, create a release branch. For example, if you're releasing Rails 3.0.10, do this:
[aaron@higgins rails (3-0-stable)]$ git checkout -b 3-0-10 Switched to a new branch '3-0-10' [aaron@higgins rails (3-0-10)]$
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.
You can review the commits for the 3.0.10 release like this:
[aaron@higgins rails (3-0-10)]$ git log v3.0.9..
IMPORTANT: Due to YAML parse problems on the rubygems.org server, it is safest to use Ruby 1.8 when releasing.
Run `rake release`. This will populate the gemspecs with data from RAILS_VERSION, commit the changes, tag it, and push the gems to rubygems.org. Here are the commands that `rake release` should use, so you can understand what to do in case anything goes wrong:
$ rake all:build $ git commit -am'updating RAILS_VERSION' $ git tag -m'tagging rc release' v3.0.10.rc1 $ git push $ git push --tags $ for i in $(ls dist); do gem push $i; done
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 lists where you should announce:
Use markdown format for your announcement. Remember to ask people to report issues with the release candidate to the rails-core mailing list.
IMPORTANT: If any users experience regressions when using the release candidate, you must postpone the release. Bugfix releases *should not* break existing applications.
If you used markdown format for your email, you can just paste it in to the blog.
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 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 commits should be added to the release branch besides regression fixing commits.
Many of these steps are the same as for the release candidate, so if you need more explanation on a particular step, so the RC steps.
You can do this, or ask the security team to do it.
FIXME: I can't remember the email addresses, but we should list them here. FIXME: Possibly we should do this the day of the RC?
Apply security patches to the release branch
Update CHANGELOG with security fixes.
Update RAILS_VERSION to remove the rc
Release the gems
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, so we need to give them the security fixes in patch form.
Merge the release branch to the stable branch.
Drink beer (or other cocktail)
There are two simple steps for fixing the CI:
Identify the problem
Repeat these steps until the CI is green.