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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
