On 9 June 2010 07:26, Chris McDonough <chr...@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 <orsent...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
