> On Tuesday, November 15, 2011 4:26:34 PM UTC+1, Jeremy Kemper wrote: > > > > Pushing a candidate is part of making that process robust and repeatable. > > It's bizarre that pushing *more* releases makes the act of pushing releases > easier. > > > The candidates are to avoid release screwups, not to capture every last > > possible bug. (3.1.2.rc1, for example.) > > I can understand why the core team tries to avoid the scenario that once led > to releasing 2.3.6 + 2.3.7 + 2.3.8 in the same day. That day, developers > didn't feel to confident about those releases because first two were > "screwups". But maybe there are ways to improve the release process and > detect "screwups" early before pushing the actual gems out. That would > eliminate the need for throwaway version numbers (i.e. RCs for patch > releases). I don't have concrete suggestions about this due to my lack of > experience for releasing software at this scale. During the 1.x and 2.x series the release process looked something like "Everyone on the core team upgrades their application, looks good, ship it". By 2.3 that was no longer feasible and, as you mentioned, we had some severe fuckups. Even during 3.0 we managed to accidentally break the router. The reality is there's no substitute for pushing a preview release and asking people to test it, despite what the TDD evangelists may tell you :)
It's more ceremony and more work for 'us', but the result is less breakage for 'you' so I think that's a good balance. -- Cheers, Koz > -- 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.
