[Python-Dev] Status of 2.7 and 3.2

Terry Reedy tjreedy at udel.edu
Sun Jun 7 23:30:23 CEST 2009

Nick Coghlan wrote:
> Martin v. Löwis wrote:
>>> I have thought that 2.7 was now to come out instead with 3.2 and would
>>> include backported 3.2 new features.  Others expect 2.7 to come out soon
>>> after 3.1 and to only contain new 3.1 features.  So Guido or someone,
>>> please clarify: is 2.7 to be the counterpart of 3.1 or 3.2?
>> Neither, nor. 2.7 will be released 18..24 months after 2.6, i.e. between
>> April 2010 and October 2010. I think it's too early to speculate about
>> a release schedule for 3.2.
> I think Terry's underlying question is more basic than that. It can also
> be phrased as:
> "Is 2.7 allowed to have new features which did not appear in 3.1?"

That is the issue that came up in a Python list discussion when two 
people, including one who I expect to know as much as me about this, 
'corrected' my 'yes' to "No, 2.7 will come out in a few months after 
3.1."  So there clearly is confusion on this and related issues (as I 
already see in the responses on this thread ;-).  The answer makes some 
difference in how issues are handled on the tracker, which I 
occasionally help with.

> In previous discussions, a general policy has been articulated that
> having released Python 3.0, any new features should appear in a 3.x
> release before they appear in a 2.x release. Following that policy
> (which I think is actually a good one) means there are certain
> consequences for the two possible answers to the above question:
> A. "No."
>   This answer means that 2.7 will only contain new features that are
> part of 3.1. If 2.7 sticks to a normal 18-24 month release cycle the
> only activities on the trunk for the next 12 months or so should be
> backports from 3.1 and bug fixes. New features added to the py3k branch
> for 3.2 should not be backported until after 2.7 is released. The other
> alternative in this case is to release 2.7 earlier than normal, but that
> creates problems in terms of the absolute duration of maintenance branch
> support for 2.6.

I agree, but this is what two people are expecting.

> B. "Yes."
>   This answer means that the 3.1 to 3.2 development cycle will need to
> be truncated by roughly 6 months so that 3.2 can be released before 2.7
> with any new features of interest. The 3.2 and 2.7 releases should then
> occur within a few months of each other.
> Releasing 2.7 early doesn't seem like a good idea to me and neither does
> putting the trunk into the equivalent of a feature freeze for 12 months
> or more. So I'm in favour of the idea of a paired 3.2/2.7 release late
> next year.

This is what I have been expecting,
> I don't think that's a novel idea though - I'm pretty sure it was
> suggested (and met with general approval) when the idea of a short
> release cycle for 3.1 was first brought up.

I presume because it has been stated before.

In addition to the question above, I am also trying to provoke thought 
on the nature and purpose of 2.7.  Backporting features 'if someone 
feels like it' seems pretty haphazard.  For someone wanting to maintain 
compatibility across multiple 2.x releases, a random new features may be 
nearly useless.

Terry Jan Reedy

More information about the Python-Dev mailing list