On 16 Jan 2014 21:54, "Kristján Valur Jónsson" <krist...@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= ccpgames....@python.org] On Behalf Of Matthias Klose > 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 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
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
