Rails Release Management

It seems with the growing complexity of the Rails infrastructure, it’s getting to be time for some more formal release management. Right now we’re in a situation (soon to be fixed, I hope) where the 2.3.2 tag on GitHub doesn’t match the 2.3.2 gems, and there are some other loose ends around the 2.3 release as well. There are a whole list of things that should be coordinated for a Rails release, and they’re pretty thoroughly decoupled at the moment:

( ) Verify build is green on Ruby 1.8.x and 1.9.1 (and potentially on other rubies in the future)
( ) Merge final release notes from docrails to rails
( ) Update CHANGELOG, version.rb and Rakefile files with final version number
( ) Tag release on GitHub
( ) Build and push gems
( ) Announce on weblog.rubyonrails.org
( ) Send out press release, update press kit (this is something the Activists team are working on for the next release)
( ) Update download graphic and release date on http://rubyonrails.org/
( ) Update release date and release notes links on http://wiki.rubyonrails.org/
( ) Push Guides content from guides.rails.info to guides.rubyonrails.org
( ) New x.x-stable branch at GitHub (not sure at what point we need to do this, may need to stay decoupled from actual release)
( ) Add new milestone to http://rails.lighthouseapp.com/projects/8994-ruby-on-rails, move any open tickets to next milestone (ideally should happen before release)

I don’t know how formal “formal” should be, or how we ought to move forward on something like this, but I do think the process could use some tweaking.

Mike

Could it be announced on the Ruby on Rails Talk list also please?
This could apply to minor releases also.
Thanks.
Colin