[python-committers] Cutting 3.3 branch now. Why not?
Georg Brandl
g.brandl at gmx.net
Fri Jun 29 10:07:32 CEST 2012
On 29.06.2012 02:23, Jesus Cea wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Python 3.3 is currently in beta, so the rythm of new patches in
> "default" will decrease and people with new features MUST wait until
> 3.3 is out. I think this is a waste of time. And even if people is
> working with HG private clones, they can't test using the buildbots
> neither mark a bug as fixed in the tracker.
>
> If we create a new 3.3 branch *NOW* and add it to the buildbots,
> people can keep working in "default" full speed (for 3.4), while 3.3
> branch is getting ready for general release. We only need to remember
> to appy the same rule current rule: any patch in branch "x" must be
> "merged" into branch "x+1" too.
>
> Has this step been considered?. I think it is a nice improvement that
> HG enables and we are not using.
>
> What do you think?.
>
> PS: In the past some people said that this "feature freeze" forces
> devs to concentrate in getting the release ready. This is a good
> point, but it should be a social issue to solve, not a technical one.
> I, for one, would personally invest more time in fixing upcoming 3.3
> (soon to be released) than hacking future 3.4 (two years away!). No
> need to "press me" with an ¿obsolete? technical limitation.
Others have already explained my motive for keeping the "technical
limitation": it is really about workload for developers.
And as Ross says: you *can* use the buildbots for personal branches.
And if you put the right "Closes #12345" in your commit messages
you don't even have to care to remember to close issues after they
are merged into mainline.
Georg
More information about the python-committers
mailing list