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