[Python-Dev] Status of 2.7 and 3.2

[Stephen J. Turnbull]

"Martin v. Löwis" writes:

 > I'm not sure that the concept of a "trunk" branch still exists in
 > Mercurial. PEP 385 apparently doesn't have resolved the branch strategy
 > for Mercurial yet. With cloned branches, I think the concept of a
 > "trunk" becomes irrelevant.

"Trunk" exists as a technical restriction in CVS, and maybe to some
extent in Subversion.  Of course that restriction is lifted by DVCSes.

But really "trunk" is a social concept.  Most projects have a trunk.
Even the anarchy known as GNU Arch converged on Tom Lord's version,
just as the storm of turbulance known as "Linux kernel development"
does on Linus's.

Python's 2.x/py3k division is a tour de force; I still can't believe
my eyes that you've pulled it off.  Consider Perl 6, LaTeX 3, and Zope
3, or Linux 3, for that matter.  The first 3 are all facing the "what
is trunk?" issue, in the case of Zope several years after the "point
oh" release, and AFAIK there are no current plans for Linux 3 (a
microkernel architecture, maybe?<1.01 wink>).  Of course the issues
faced by LaTeX, Zope, and the kernel are quite different from
Python's, and I don't know enough about Perl internals to compare.

So I think "trunk" does matter.  But it's not entirely in the power of
the Python committers, not even the BDFL, to determine what "trunk" is.

>>>>> Terry Reedy writes:

 > > A. As long as 2.x is 'trunk', some people will view 3.x as
 > > 'experimental'.  That was true for 3.0, but (much?) less so for 3.1.  Is
 > > there any known reason why 3.2 should not soon be considered and treated
 > > as the main development version, to become the main production version?

Yes.  User/developers may prefer strongly prefer the stability of
2.x.  That's the problem of being a successful product, you lose
agility almost by definition.

 > > B. All new features will go into 3.2.  Only some will be backported to
 > > 2.x.  So it seems that the flow should be to develop for 3.2 and maybe
 > > backport thereafter.
 > 
 > What about bug fixes? How will they flow?

This has to be ad hoc, at least at first.  Some bugs will be uncovered
in each version.  The solutions will often not be the same in the
different versions.  Many developers will be downstream, and only
willing to contribute the patch for the version they use.

 > > B. Do we really want to encourage library developers to put their
 > > 'upgrade to a new version' energy into 2.x to 2.x+1 upgrades, rather
 > > than a 2.x to 3.y upgrades?
 > 
 > IMO, it's much up to the contributors.

I think so, too.  Terry's word "encourage" is appropriate here,
though, and at some point that question will need to be answered.  I
think he's right to raise it early.