From 6b8091731445dcd0a1843c59b84cd4e2b5b8b66c Mon Sep 17 00:00:00 2001 From: Aaron Patterson Date: Thu, 4 Aug 2011 11:27:26 -0700 Subject: adding my brain dump of the release process --- RELEASING_RAILS.rdoc | 163 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 163 insertions(+) create mode 100644 RELEASING_RAILS.rdoc (limited to 'RELEASING_RAILS.rdoc') diff --git a/RELEASING_RAILS.rdoc b/RELEASING_RAILS.rdoc new file mode 100644 index 0000000000..2d8d8c5f95 --- /dev/null +++ b/RELEASING_RAILS.rdoc @@ -0,0 +1,163 @@ += 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 +really be considered as minimums. + +== 10 Days before release + +Today is mostly coordination tasks. Here are the things you must do today: + +=== Contact the security team (either Koz or tenderlove) + +Let them know of your plans to release. There may be security issues to be +addressed, and that can impact your release date. + +=== 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: + + http://travis-ci.org/#!/rails/rails + +=== Is Sam Ruby happy? If not, make him happy. + +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: + + http://intertwingly.net/projects/dashboard.html + +Do not release with Red AWDwR tests. + +=== 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. +Contact the authors of those particular gems and work out a release date that +suites them. + +== 3 Days before release + +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 Sam Ruby happy? If not, make him happy. + +=== 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 +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)]$ + +=== Update each CHANGELOG. + +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.. + +=== Update the RAILS_VERSION file to include the RC. + +=== Release the gem. + +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 + $ for i in $(ls dist); do gem push $i; 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 +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 +issues with the release candidate to the rails-core mailing list. + +IMPORTANT: If anything users experience regressions when using the release +candidate, you *must* postpone the release. Bugfix releases *should not* +break existing applications. + +=== Post the announcement to the Rails blog. + +If you used markdown format for your email, you can just paste it in to the +blog. + +* http://weblog.rubyonrails.org + +=== Post the announcement to the Rails twitter account. + +== Time between release candidate and actual release + +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. + +== Day of release + +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. + +=== Email the rails security announce list, once for each vulnerability fixed. + +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 +* Email announcement + +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. + +* Blog announcements +* Twitter announcements +* Merge the release branch to the stable branch. +* Drink beer (or other cocktail) + +== Misc + +=== Fixing the CI + +There are two simple steps for fixing the CI: + +1. Identify the problem +2. Fix it + +Repeat these steps until the CI is green. -- cgit v1.2.3 From 886d0115dc766865eada9308839ee827d9f13cad Mon Sep 17 00:00:00 2001 From: Aaron Patterson Date: Thu, 4 Aug 2011 12:00:06 -0700 Subject: fixing wrong words. thanks @jbrown --- RELEASING_RAILS.rdoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'RELEASING_RAILS.rdoc') diff --git a/RELEASING_RAILS.rdoc b/RELEASING_RAILS.rdoc index 2d8d8c5f95..98453db549 100644 --- a/RELEASING_RAILS.rdoc +++ b/RELEASING_RAILS.rdoc @@ -97,7 +97,7 @@ 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 anything users experience regressions when using the release +IMPORTANT: If any users experience regressions when using the release candidate, you *must* postpone the release. Bugfix releases *should not* break existing applications. -- cgit v1.2.3 From bf0b6e4b8b1df8114ab0208686bc4cffb0851877 Mon Sep 17 00:00:00 2001 From: Aaron Patterson Date: Thu, 4 Aug 2011 14:13:41 -0700 Subject: add section about notifying implementors --- RELEASING_RAILS.rdoc | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'RELEASING_RAILS.rdoc') diff --git a/RELEASING_RAILS.rdoc b/RELEASING_RAILS.rdoc index 98453db549..f780f58f2f 100644 --- a/RELEASING_RAILS.rdoc +++ b/RELEASING_RAILS.rdoc @@ -14,6 +14,20 @@ Today is mostly coordination tasks. Here are the things you must do today: 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 +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: + +* team@jruby.org +* community@rubini.us +* rubyonrails-core@googlegroups.com + +Implementors will love you and help you. + === 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: -- cgit v1.2.3 From 5399b2028712e0fc3bb768ee3c0a836ea4859909 Mon Sep 17 00:00:00 2001 From: Aaron Patterson Date: Thu, 4 Aug 2011 14:15:45 -0700 Subject: moving CI and Sam Ruby to the top of the list. I :heart: CI and Sam --- RELEASING_RAILS.rdoc | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) (limited to 'RELEASING_RAILS.rdoc') diff --git a/RELEASING_RAILS.rdoc b/RELEASING_RAILS.rdoc index f780f58f2f..22fc58516e 100644 --- a/RELEASING_RAILS.rdoc +++ b/RELEASING_RAILS.rdoc @@ -9,25 +9,6 @@ really be considered as minimums. Today is mostly coordination tasks. Here are the things you must do today: -=== Contact the security team (either Koz or tenderlove) - -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 -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: - -* team@jruby.org -* community@rubini.us -* rubyonrails-core@googlegroups.com - -Implementors will love you and help you. - === 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: @@ -51,6 +32,25 @@ 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. +=== Contact the security team (either Koz or tenderlove) + +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 +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: + +* team@jruby.org +* community@rubini.us +* rubyonrails-core@googlegroups.com + +Implementors will love you and help you. + == 3 Days before release This is when you should release the release candidate. Here are your tasks -- cgit v1.2.3 From 5852fcfb118156abcd8912de5279f7dac91c4b3d Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 4 Aug 2011 18:43:13 -0300 Subject: Add git push and git push --tags to RELEASING_RAILS.rdoc --- RELEASING_RAILS.rdoc | 2 ++ 1 file changed, 2 insertions(+) (limited to 'RELEASING_RAILS.rdoc') diff --git a/RELEASING_RAILS.rdoc b/RELEASING_RAILS.rdoc index 22fc58516e..e3d3f67237 100644 --- a/RELEASING_RAILS.rdoc +++ b/RELEASING_RAILS.rdoc @@ -96,6 +96,8 @@ 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 === Send Rails release announcements -- cgit v1.2.3 From f566fb32c49a81636ca341f376f99ef230d71d99 Mon Sep 17 00:00:00 2001 From: Waynn Lue Date: Fri, 12 Aug 2011 17:23:16 -0700 Subject: "suits" is correct here, not "suites" --- RELEASING_RAILS.rdoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'RELEASING_RAILS.rdoc') diff --git a/RELEASING_RAILS.rdoc b/RELEASING_RAILS.rdoc index e3d3f67237..4a9a875bfa 100644 --- a/RELEASING_RAILS.rdoc +++ b/RELEASING_RAILS.rdoc @@ -30,7 +30,7 @@ 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. +suits them. === Contact the security team (either Koz or tenderlove) -- cgit v1.2.3 From b0555bb88b090ca981fcc7661b6f9ea333e7f42e Mon Sep 17 00:00:00 2001 From: Aaron Patterson Date: Tue, 16 Aug 2011 11:29:54 -0700 Subject: adding security email address --- RELEASING_RAILS.rdoc | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'RELEASING_RAILS.rdoc') diff --git a/RELEASING_RAILS.rdoc b/RELEASING_RAILS.rdoc index 4a9a875bfa..c2ba4e7857 100644 --- a/RELEASING_RAILS.rdoc +++ b/RELEASING_RAILS.rdoc @@ -149,8 +149,7 @@ 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? +Email the security reports to: rubyonrails-security@googlegroups.com * Apply security patches to the release branch * Update CHANGELOG with security fixes. -- cgit v1.2.3 From 9d9f59139ea4db9ac6e55defc5156f8e8ab580f8 Mon Sep 17 00:00:00 2001 From: Aaron Patterson Date: Tue, 16 Aug 2011 16:30:29 -0700 Subject: adding lessons learned so I do not make the same mistake twice --- RELEASING_RAILS.rdoc | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'RELEASING_RAILS.rdoc') diff --git a/RELEASING_RAILS.rdoc b/RELEASING_RAILS.rdoc index c2ba4e7857..f4197e0eb2 100644 --- a/RELEASING_RAILS.rdoc +++ b/RELEASING_RAILS.rdoc @@ -145,6 +145,11 @@ 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. +=== Release the gem. + +See steps for releasing the RC. Make sure to release the gem before +announcing security issues in the next step. + === Email the rails security announce list, once for each vulnerability fixed. You can do this, or ask the security team to do it. -- cgit v1.2.3 From 22e611ed5b0a708d17ef2e7574bcdf2edf2db01b Mon Sep 17 00:00:00 2001 From: Aaron Patterson Date: Tue, 16 Aug 2011 17:39:58 -0700 Subject: making the order more clear, adding linux distros mailing lists to our cc --- RELEASING_RAILS.rdoc | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) (limited to 'RELEASING_RAILS.rdoc') diff --git a/RELEASING_RAILS.rdoc b/RELEASING_RAILS.rdoc index f4197e0eb2..cbc9d0e1de 100644 --- a/RELEASING_RAILS.rdoc +++ b/RELEASING_RAILS.rdoc @@ -145,22 +145,25 @@ 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. -=== Release the gem. +Today, do this stuff in this order: + +* Apply security patches to the release branch +* Update CHANGELOG with security fixes. +* Update RAILS_VERSION to remove the rc +* Release the gems +* Email security lists +* Email general announcement lists -See steps for releasing the RC. Make sure to release the gem before -announcing security issues in the next step. +=== Emailing the rails security announce list -=== Email the rails security announce list, once for each vulnerability fixed. +Email the security announce list once for each vulnerability fixed. You can do this, or ask the security team to do it. -Email the security reports to: rubyonrails-security@googlegroups.com +Email the security reports to: -* Apply security patches to the release branch -* Update CHANGELOG with security fixes. -* Update RAILS_VERSION to remove the rc -* Release the gems -* Email announcement +* rubyonrails-security@googlegroups.com +* linux-distros@vs.openwall.org 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, -- cgit v1.2.3 From c7b84689a4d59b9f2c5773b6a8527adb68e04560 Mon Sep 17 00:00:00 2001 From: Jon Leighton Date: Mon, 14 Nov 2011 11:29:57 +0000 Subject: Add note about syncing CHANGELOGs --- RELEASING_RAILS.rdoc | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'RELEASING_RAILS.rdoc') diff --git a/RELEASING_RAILS.rdoc b/RELEASING_RAILS.rdoc index cbc9d0e1de..b7ebc4600c 100644 --- a/RELEASING_RAILS.rdoc +++ b/RELEASING_RAILS.rdoc @@ -81,6 +81,10 @@ You can review the commits for the 3.0.10 release like this: [aaron@higgins rails (3-0-10)]$ git log v3.0.9.. +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. === Release the gem. -- cgit v1.2.3 From 4d8081b6e7ffa88b4fc74187fb1599ef9b27e6ed Mon Sep 17 00:00:00 2001 From: Jon Leighton Date: Mon, 14 Nov 2011 12:08:03 +0000 Subject: Add note about checking postgres tests before release --- RELEASING_RAILS.rdoc | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'RELEASING_RAILS.rdoc') diff --git a/RELEASING_RAILS.rdoc b/RELEASING_RAILS.rdoc index b7ebc4600c..bd75b36b2a 100644 --- a/RELEASING_RAILS.rdoc +++ b/RELEASING_RAILS.rdoc @@ -25,6 +25,12 @@ for Rails. You can check the status of his tests here: Do not release with Red AWDwR tests. +=== Are the postgres tests green? If not, make them green + +Currently Travis CI doesn't run the Active Record postgres tests. They are +working to resolve this, but in the mean time, it is crucial to ensure that +the tests are still green before release. + === Do we have any git dependencies? If so, contact those authors. Having git dependencies indicates that we depend on unreleased code. @@ -60,6 +66,8 @@ for today: === Is Sam Ruby happy? If not, make him happy. +=== Are the postgres tests green? If not, make them green + === Contact the security team. CVE emails must be sent on this day. === Create a release branch. -- cgit v1.2.3 From be777b30d581aa3488f1c7be14783b58a1567b82 Mon Sep 17 00:00:00 2001 From: Jon Leighton Date: Mon, 14 Nov 2011 17:08:24 +0000 Subject: Add a note to REALEASING_RAILS about testing the gem locally before releasing --- RELEASING_RAILS.rdoc | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'RELEASING_RAILS.rdoc') diff --git a/RELEASING_RAILS.rdoc b/RELEASING_RAILS.rdoc index bd75b36b2a..1dfcfe2488 100644 --- a/RELEASING_RAILS.rdoc +++ b/RELEASING_RAILS.rdoc @@ -95,6 +95,14 @@ branch. === Update the RAILS_VERSION file to include the RC. +=== Build and test the gem. + +Run `rake install` to generate the gems and install them locally. Then try +generating a new app and ensure that nothing explodes. + +This will stop you looking silly when you push an RC to rubygems.org and then +realise it is broken. + === Release the gem. IMPORTANT: Due to YAML parse problems on the rubygems.org server, it is safest @@ -162,6 +170,7 @@ Today, do this stuff in this order: * Apply security patches to the release branch * Update CHANGELOG with security fixes. * Update RAILS_VERSION to remove the rc +* Build and test the gem * Release the gems * Email security lists * Email general announcement lists -- cgit v1.2.3 From 307fc122f6b6c38204ffc6040fc8d814a8f01325 Mon Sep 17 00:00:00 2001 From: Xavier Noria Date: Fri, 18 Nov 2011 13:05:25 +0100 Subject: release instructions: new section about docs generation --- RELEASING_RAILS.rdoc | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) (limited to 'RELEASING_RAILS.rdoc') diff --git a/RELEASING_RAILS.rdoc b/RELEASING_RAILS.rdoc index 1dfcfe2488..3f05e97b91 100644 --- a/RELEASING_RAILS.rdoc +++ b/RELEASING_RAILS.rdoc @@ -205,3 +205,34 @@ There are two simple steps for fixing the CI: 2. Fix it Repeat these steps until the CI is green. + +=== Manually trigger docs generation + +We have a post-receive hook in GitHub that calls the docs server on pushes. +Triggers generation and publication of edge docs, updates the contrib app, +and generates and publishes stable docs if a new stable tag is detected. + +The hook unfortunately is not invoked by tag pushing, so once the new stable +tag has been pushed to origin, please run + + curl -X POST -d '' http://rails-hooks.hashref.com/rails-master-hook + +You should see something like this: + + Rails master hook tasks scheduled: + + * updates the local checkout + * updates Rails Contributors + * generates and publishes edge docs + + If a new stable tag is detected it also + + * generates and publishes stable docs + + This needs typically a few minutes. + +Note you do not need to specify the tag, the docs server figures it out. + +Also, don't worry if you call that multiple times or the hook is triggered +again by some immediate regular push, if the scripts are running new calls +are just queued (in a queue of size 1). -- cgit v1.2.3 From 6fc2e12ec5814658da26de8b0d9c1ffb4365dfa0 Mon Sep 17 00:00:00 2001 From: Hendy Tanata Date: Fri, 18 Nov 2011 11:22:18 -0800 Subject: Some fixes on RELEASING_RAILS.rdoc. --- RELEASING_RAILS.rdoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'RELEASING_RAILS.rdoc') diff --git a/RELEASING_RAILS.rdoc b/RELEASING_RAILS.rdoc index 3f05e97b91..9f25adeccc 100644 --- a/RELEASING_RAILS.rdoc +++ b/RELEASING_RAILS.rdoc @@ -100,8 +100,8 @@ branch. Run `rake install` to generate the gems and install them locally. Then try generating a new app and ensure that nothing explodes. -This will stop you looking silly when you push an RC to rubygems.org and then -realise it is broken. +This will stop you from looking silly when you push an RC to rubygems.org and +then realise it is broken. === Release the gem. @@ -209,7 +209,7 @@ Repeat these steps until the CI is green. === Manually trigger docs generation We have a post-receive hook in GitHub that calls the docs server on pushes. -Triggers generation and publication of edge docs, updates the contrib app, +It triggers generation and publication of edge docs, updates the contrib app, and generates and publishes stable docs if a new stable tag is detected. The hook unfortunately is not invoked by tag pushing, so once the new stable -- cgit v1.2.3