On Mon, Aug 13, 2012 at 11:02:17AM -0400, Mike Rylander wrote: > On Mon, Aug 13, 2012 at 9:35 AM, Bill Erickson <[email protected]> > wrote: > > > > Hi All, > > > > I'm planning on cutting 2.3.beta2 this Friday 8/17. Keep the bug fixes > > rolling! > > > > After that comes the 2.3.rc1 release candidate on August 31st. I'm not > > anticipating an RC2, but we can certainly squeeze one in if necessary. > > > > <policy> > > How do we characterize bug fixes that are allowed to be merged between RC1 > > and GA? I assume we should limit to showstoppers only? > > </policy> > > IMO (and likely debatable), we shouldn't cut RC until showstoppers are > in, and post-RC bug fixes should be limited to low-impact or > high-priority fixes. Thoughts?
I agree any showstoppers we are aware of should be addressed pronto, before any RC is cut (and ideally before beta2). I'm treating RC as "this is what you are getting, unless we find something truly messed up in there" ;). It occurs to me the interval between RC1 and GA is fairly large, though, and there will be a (well intentioned) desire to fill that space with bug fixes. Given that every bug fix is a potential new bug, though, I'm inclined to lean toward only allowing very high priority fixes. If it would help solidify that RC /is effectively/ GA, we could move the RC date up closer to the GA date to allow for a little longer beta bug fixing period. -b -- Bill Erickson | Senior Software Developer | phone: 877-OPEN-ILS (673-6457) | email: [email protected] | web: http://esilibrary.com | Equinox Software, Inc. / Your Library's Guide to Open Source
