Re: [Python-Dev] Python-Dev Digest, Vol 76, Issue 87
Stop email
Sent from my BlackBerry®
powered by Sinyal Kuat INDOSAT
-----Original Message-----
From: python-dev-request@python.org
Date: Tue, 10 Nov 2009 23:09:45
To:
PEP 3003 states that Python 3.2 will be released 18-24 months after Python 3.1. Python 3.1 was released on June 2009-06-27 [1], so theoretically Python 3.2 should be released not before 2010-12-19 [2].
The PEP 3003 text isn't allowing for the fact that 3.1 is "3.0 as it should have been", so the starting point for the 18-24 month rule of thumb is actually back when 3.0 was released in Dec 2008. This was discussed a fair bit back when the decision was made to do the short release cycle between 3.0 and 3.1 in order to address some of the more glaring shortcomings of the 3.0 release.
I agree with everybody else who said that
a) there was *no* consensus that the release cycle for 3.2 should be
shortened because of 3.1 being released early. I also remember the
opposite.
b) whatever past discussion may have been, it would be a mistake to
release 3.2 earlier than 18 months after 3.1.
Of course, 2.7 *could* be released by the proposed schedule; it just
would have to be decoupled from 3.2 (just as 2.6 eventually got
decoupled from 3.0).
I personally think that decoupling the releases would be best, i.e.
not start thinking about 3.2 for another 6 months.
Regards,
Martin
------------------------------
Message: 2
Date: Wed, 11 Nov 2009 07:16:50 +1000
From: Nick Coghlan
PEP 3003 states that Python 3.2 will be released 18-24 months after Python 3.1. Python 3.1 was released on June 2009-06-27 [1], so theoretically Python 3.2 should be released not before 2010-12-19 [2]. The PEP 3003 text isn't allowing for the fact that 3.1 is "3.0 as it should have been", so the starting point for the 18-24 month rule of thumb is actually back when 3.0 was released in Dec 2008. This was discussed a fair bit back when the decision was made to do the short release cycle between 3.0 and 3.1 in order to address some of the more glaring shortcomings of the 3.0 release.
I agree with everybody else who said that
a) there was *no* consensus that the release cycle for 3.2 should be shortened because of 3.1 being released early. I also remember the opposite.
b) whatever past discussion may have been, it would be a mistake to release 3.2 earlier than 18 months after 3.1.
Fair enough - I didn't remember that discussion all that well, but assumed it had reached that consensus due to the lack of comment when Benjamin originally posted his proposed schedule. Your response and Guido's clearly indicate otherwise :) If that wasn't the consensus, then all the dates should slide back 6 months (i.e. no alphas until June 2010). (I actually prefer that since it gives me a chance to find a cleaner approach to the runpy.run_path problem, but didn't want to rehash a discussion I thought we had already had)
Of course, 2.7 *could* be released by the proposed schedule; it just would have to be decoupled from 3.2 (just as 2.6 eventually got decoupled from 3.0).
That leads to a 2.x version with features that aren't yet available in a 3.x version though. I thought we weren't planning on doing that anymore.
I personally think that decoupling the releases would be best, i.e. not start thinking about 3.2 for another 6 months.
Or just have the timing be 18 months for 3.2 and 24 months for 2.7 (i.e.
push the first alpha of both back to June next year).
Cheers,
Nick.
--
Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
---------------------------------------------------------------
------------------------------
Message: 3
Date: Tue, 10 Nov 2009 21:26:24 +0000 (UTC)
From: Antoine Pitrou
I would remove them -- if and when we find there's a need for something like them I suspect it won't look like what you currently have, so it's better not to complexificate your current patch with them. (I would remove all traces, including the conditions passed into the end macros.)
My only suggestion so far: the description could use more explicit documentation on the various variables and macros and how they combine.
Is it before or after http://mail.python.org/pipermail/python-checkins/2009-
November/087482.html ?
After. While that is already really helpful, not all the code is easily linked back to paragraphs in that comment block, and some variables are not mentioned by name in the block.
------------------------------
Message: 4
Date: Tue, 10 Nov 2009 21:50:26 +0000 (UTC)
From: Antoine Pitrou
The buildbot waterfall is much greener now. Thanks to all who have contributed to making it so (and it hasn't just been Mark and Antoine and I, though we've been the most directly active (and yes, Mark, you did contribute several fixes!)).
The buildbots still show occasional oddities. For example, right now in
the page "http://www.python.org/dev/buildbot/3.x/", some results have
disappeared (the columns for "AMD64 Ubuntu" builders have become empty).
Moreover, some buildslaves have gone back in time (they are building
r76188 after having built and tested r76195)... I swear the new GIL
doesn't include a time machine.
Regards
Antoine.
------------------------------
Message: 5
Date: Tue, 10 Nov 2009 23:06:14 +0100
From: "Martin v. L?wis"
The buildbot waterfall is much greener now. Thanks to all who have contributed to making it so (and it hasn't just been Mark and Antoine and I, though we've been the most directly active (and yes, Mark, you did contribute several fixes!)).
The buildbots still show occasional oddities. For example, right now in the page "http://www.python.org/dev/buildbot/3.x/", some results have disappeared (the columns for "AMD64 Ubuntu" builders have become empty).
Yes, I noticed it too. It will go away after some page reloads.
Moreover, some buildslaves have gone back in time (they are building r76188 after having built and tested r76195)... I swear the new GIL doesn't include a time machine.
That's because I resubmitted these changes after restarting the master.
Regards,
Martin
------------------------------
Message: 6
Date: Tue, 10 Nov 2009 16:06:46 -0600
From: Benjamin Peterson
I personally think that decoupling the releases would be best, i.e. not start thinking about 3.2 for another 6 months.
The problem with that is that there is a period of time where 2.x has
features which 3.x doesn't. My preference is to move back the whole
schedule 6 months.
--
Regards,
Benjamin
------------------------------
Message: 7
Date: Tue, 10 Nov 2009 23:09:42 +0100
From: "Martin v. L?wis"
2009/11/10 "Martin v. L?wis"
: I personally think that decoupling the releases would be best, i.e. not start thinking about 3.2 for another 6 months.
The problem with that is that there is a period of time where 2.x has features which 3.x doesn't. My preference is to move back the whole schedule 6 months.
Ok, fine with me as well. FWIW, I don't see that (2.7 released before 3.2) as a problem (but I understand that others might, for what I would consider formal reasons). Regards, Martin ------------------------------ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev End of Python-Dev Digest, Vol 76, Issue 87 ******************************************
participants (1)
-
wa2n39@gmail.com