A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2010-June/100522.html below:

[Python-Dev] Future of 2.x.

[Python-Dev] Future of 2.x.Paul Moore p.f.moore at gmail.com
Wed Jun 9 13:58:17 CEST 2010
On 9 June 2010 07:26, Chris McDonough <chrism at plope.com> wrote:
> On Wed, 2010-06-09 at 01:15 -0400, Fred Drake wrote:
>> On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran <orsenthil at gmail.com> wrote:
>> > it would still be a good idea to
>> > introduce some of them in minor releases in 2.7. I know, this
>> > deviating from the process, but it could be an option considering that
>> > 2.7 is the last of 2.x release.
>>
>> I disagree.
>>
>> If there are going to be features going into *any* post 2.7.0 version,
>> there's no reason not to increment the revision number to 2.8,
>>
>> Since there's also a well-advertised decision that 2.7 will be the
>> last 2.x, such a 2.8 isn't planned.  But there's no reason to violate
>> the no-features-in-bugfix-releases policy.  We've seen violations
>> cause trouble and confusion, but we've not seen it be successful.
>>
>> The policy wasn't arbitrary; let's stick to it.
>
> It might be useful to copy the identifiers and URLs of all the backport
> request tickets into some other repository, or to create some unique
> state in roundup for these.  Rationale: it's almost certain that if the
> existing Python core maintainers won't evolve Python 2.X past 2.7, some
> other group will, and losing existing context for that would kinda suck.

Personally, as a user of Python, I'm already getting tired of the "we
won't let Python 2.x die" arguments. Unless and until some other group
comes along and says they definitely plan to pick up Python 2.x
development (and set up or agree shared usage of all the relevant
infrastructure, bug tracker, developers list, VCS, etc) I see the core
developers' decision as made. 2.7 is the last Python 2.x release, and
all further development will be on 3.x.

On that basis I'm +1 on Alexandre's proposal. A 3rd party planning on
working on a 2.8 release (not that I think such a party currently
exists) can step up and extract the relevant tickets for their later
reference if they feel the need. Let's not stop moving forward for the
convenience of a hypothetical 2.8 development team.

Paul.
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4