On 16 Jan 2014 21:54, "Kristján Valur Jónsson" <kristjan@ccpgames.com> wrote:
I suppose different projects have different ways, but I'm actually
talking about commercial projects with which I am somewhat familiar.
Once a project goes into feature freeze, it is branched off so that continued feature development can commence, while Defects are ironed out in the branch. Bugs obviously get priority. This also applies to open source, I should think. Meanwhile, a keen contributor does not have to sit idle waiting for an extended RC phase to play out.
It's a social hack to remind people that the current focus is supposed to be on ironing out issues in the imminent release, with the subsequent release deliberately deemphasised until the current one is out. (PEP 461 is a bit of an aberration, since people wanted to ensure we had a solid plan in place for bringing binary interpolation back for 3.5, and also at least asked the question about doing so in 3.4)
The commercial world has different ways of dealing with the focus problem, since there's a more direct relationship between an employer and an employee than there is between a CPython release manager and other contributors. For us, though, it's useful to have the state of the branches reflect current priorities (plus we want to minimise the amount of time we have two maintenance branches open).
Cheers, Nick.
K
-----Original Message----- From: python-committers [mailto:python-committers-bounces+kristjan=
Sent: Thursday, January 16, 2014 19:27 To: python-committers@python.org Subject: Re: [python-committers] Updated schedule for Python 3.4
Am 16.01.2014 12:17, schrieb Kristján Valur Jónsson:
This is such an obvious question that it probably has been raised before, but anyway: Why not branch 3.4 earlier than release? That is how big projects are managed nowadays, you create a staging branch early. I'd suggest branching it off at b3. There is no reason to keep all
ccpgames.com@python.org] On Behalf Of Matthias Klose trunk development frozen just because a particular version is in RC mode.
Big projects (like GCC) delay the branching as long as possible and only
branch when the trunk reaches release quality. Branch maintenance eats developer resources, and usually opening the trunk for new development distracts developers from contributing to the release. I do like the way how this is done for Python (and GCC).
Matthias
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers