Anthony Baxter wrote:
Brett C. wrote:
Anthony Baxter wrote:
My approach to the bug fix releases is that, in general, "there's always a next release". That is, the bug fix releases are relatively frequent (5-6 months) and they're "what's in the branch at the moment".
OK. How long do you plan to do this for the 2.3 branch?
I'm anticipating doing this until 2.4.1. That is, the upcoming release train will be:
2.3.4 2.4a{1,2,...} 2.4b{1,2,...} 2.4rc{1,2,...} 2.4 2.3.5 2.4.1
Unless there's a pressing need for it, I don't see the point to cutting a 2.3.6 or later, once 2.4 is onto the release24-maint branch. Obviously, if there's one of the oh-my-gods type bugs in 2.3, this will probably require a 2.3.6. Hopefully, by the time I finish the 2.4 cycle, there'll be some sane release automation tools finished, too.
Anything us normal folk can help you with in terms of the aforementioned tools? Maybe this could encompass a tool to run the testing suite, re-run the failed tests with verbose output, and then email them to a Mailman list with system info so we have a partially automated testing framework for alphas, betas, and release candidates (Christopher Blunck proposed this idea back in March; email at http://mail.python.org/pipermail/python-dev/2004-March/043492.html) since we currently don't have a testing server farm running regularly anymore? -Brett