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. Once we've forked release24-maint, release23-maint can start to die. There's no point backporting patches to two separate -maint branches.
Getting into a regular groove for releases sounds great to me, especially if we can state confidently that a bugfix release will be along every 6 months (+/- a month).
Yep. I plan to update the bug fix release PEP and post it out to
c.l.py and python-dev for feedback.
As ever, I'm open to feedback on any of the above. Except for the
"can we please have this whizzo feature in the next bug fix release"
feedback. You know the answer to that one ;)
--
Anthony Baxter