[Python-Dev] for __future__ import planning

[Brett Cannon]

On Fri, Oct 3, 2008 at 3:56 PM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Oct 3, 2008, at 5:26 PM, Benjamin Peterson wrote:
>
>> So now that we've released 2.6 and are working hard on shepherding 3.0
>> out the door, it's time to worry about the next set of releases. :)
>>
>> I propose that we dramatically shorten our release cycle for 2.7/3.1
>> to roughly a year and put a strong focus stabilizing all the new
>> goodies we included in the last release(s). In the 3.x branch, we
>> should continue to solidify the new code and features that were
>> introduced. One 2.7's main objectives should be binding 3.x and 2.x
>> ever closer.
>
> There are several things that I would like to see us concentrate on after
> the 3.0 release.  I agree that 3.1 should be primarily a stabilizing
> release.  I suspect that we will find a lot of things that need tweaking
> only after 3.0 final has been out there for a while.
>
> I think 2.7 should continue along the path of convergence toward 3.x.  The
> vision some of us talked about at Pycon was that at some point down the
> line, maybe there's no difference between "python2.9 -3" and "python3.3 -2".
>

+1 from me. I think 2.7/3.1 should be used as a chance to get our
testing framework straightened out and have those releases be
extremely rock-solid (especially 2.7 as it might be the last in the
2.x series).

Oh, and getting import rewritten in pure Python for 3.1 of course. =)

> I would really like to see us adopt a distributed version control system.
>

Along the lines of making 2.7/3.1 very stable releases, I would love
to use the time to clean up our workflow. To me that means cleaning up
the workflow on the issue tracker and getting on to a DVCS to make it
as easy as possible for people to contribute patches and for us to do
reviews.

> I want our maintenance branches to always be in a releasable state.  I want
> to be confident enough about the tree to be able to cut a point release at
> any time.  I want to release a new point release from the maint branches
> once a month.
>

Wow! I guess release.py is going to get really automated then. =) That
or you are going to manage to con more of us to help out (and even cut
the release ourselves).

> Christian rightly points out that with four active trees, we're going to a
> pretty big challenge on our hands.  How do other large open source projects
> handle similar situations?
>

Beats me. Are that many projects crazy enough to have that many active branches?

-Brett