I think the fact that I messed up rc1 is testament to the fact that RCs are a good idea ;)
But in general, doing releases is a big hassle. Therefore, I would prefer to encounter this hassle on my own schedule, not in the middle of the night when I've just messed up a 'real' release and am racing against the clock to push out a fixed one. On Tue, 2011-11-15 at 13:13 -0800, Yehuda Katz wrote: > Indeed. Advocating that we go back to what we did before is a big > mistake. Releasing actual gems is the best way to make sure that > people know about the impending release and have an opportunity to try > it out and discover mistakes. In fact, the RC releases we have done > *have* discovered mistakes. I don't want to build a process around the > assumption of no mistakes. > > Yehuda Katz > (ph) 718.877.1325 > > > On Tue, Nov 15, 2011 at 7:26 AM, Jeremy Kemper > <[email protected]> wrote: > On Tue, Nov 15, 2011 at 6:36 AM, Mislav > <[email protected]> wrote: > > Rails 3.1.2.rc2 just got released. Around the time of > the 3.1.1 release, there was also a relatively evolved > release process including announcements and release > candidates. > > > Why? > > > Standardizing the process makes it easier to manage frequent > releases. > > > Pushing a candidate is part of making that process robust and > repeatable. > > > > > In other words, bugfix releases are cheap. Why waste > time with release candidates when we can just get > 3.1.2 right away? Then, every fix that would otherwise > be made between 3.1.2.rc2-3.1.2 can just be released > as 3.1.3. > > > The candidates are to avoid release screwups, not to capture > every last possible bug. (3.1.2.rc1, for example.) > > > I love the spirit behind doing point releases like crazy and > recovering quickly from issues with new point releases. But > our experience shows that actually leads to *less frequent* > releases. > > > -- http://jonathanleighton.com/
signature.asc
Description: This is a digitally signed message part
