Release candidate followed by feature freeze?
I'm considering to issue a release candidate before the final 2.0 release. I'd like to poll opinions about this (we haven't had a PythonLabs group meeting about this yet). The importance of a release candidate (RC) is twofold: we announce it widely so it (hopefully) gets a lot of testing -- necessary since a lot of things have changed again since beta2; and we impose a checkin stop once the RC is out, with exceptions only allowed by the release manager to fix showstopper bugs found in the RC. This will hopefully avoid a disaster like we had with the buggy last-minute changes in beta2 (for which I take full responsibility). If the idea of a RC sounds okay, I'd like to propose to release it on October 5. The final release would still be on October 10, or perhaps 1-2 days later. Much less than a week between the RC and the final release is not good because it doesn't give testers enough time to try out the RC; much more than a week is bad because the developers get antsy when they can't check in their changes! This means that any current bug reports and patches that aren't in the RC, WON'T BE FIXED in the final release! Think about it. This is a good thing, so we won't be able to screw up the final release at the last moment. --Guido van Rossum (home page: http://www.python.org/~guido/)
guido wrote:
If the idea of a RC sounds okay
Sure does.
I'd like to propose to release it on October 5.
Hmm. My plan was to to work on the remaining SRE issues on Saturday, leaving Sunday-Tuesday for final "burn-in"...
Also FYI, I intend applying the previous-version-crash patch tomorrow (or late today), so those extra few days for /F would also prevent this patch going out _too_ green... Mark.
participants (3)
-
Fredrik Lundh
-
Guido van Rossum
-
Mark Hammond