2.7/3.2 release schedule
I've updated PEP 373 with my proposed release schedule: - 2.7/3.2 alpha 1 2009-12-05 - 2.7/3.2 alpha 2 2010-01-09 - 2.7/3.2 alpha 3 2010-02-06 - 2.7/3.2 alpha 4 2010-03-06 - 2.7/3.2 beta 1 2010-04-03 - 2.7/3.2 beta 2 2010-05-01 - 2.7/3.2 rc1 2010-05-29 - 2.7/3.2 rc2 2010-06-12 - 2.7/3.2 final 2010-06-26 -- Regards, Benjamin
2009-11-02 21:00 Benjamin Peterson <benjamin@python.org> napisał(a):
I've updated PEP 373 with my proposed release schedule:
- 2.7/3.2 alpha 1 2009-12-05 - 2.7/3.2 alpha 2 2010-01-09 - 2.7/3.2 alpha 3 2010-02-06 - 2.7/3.2 alpha 4 2010-03-06 - 2.7/3.2 beta 1 2010-04-03 - 2.7/3.2 beta 2 2010-05-01 - 2.7/3.2 rc1 2010-05-29 - 2.7/3.2 rc2 2010-06-12 - 2.7/3.2 final 2010-06-26
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]. [1] http://python.org/download/releases/3.1/ [2] datetime.date(2009, 6, 27) + datetime.timedelta(18 * 30) -- Arfrever Frehtes Taifersar Arahesis
Arfrever Frehtes Taifersar Arahesis wrote:
2009-11-02 21:00 Benjamin Peterson <benjamin@python.org> napisał(a):
I've updated PEP 373 with my proposed release schedule:
- 2.7/3.2 alpha 1 2009-12-05 - 2.7/3.2 alpha 2 2010-01-09 - 2.7/3.2 alpha 3 2010-02-06 - 2.7/3.2 alpha 4 2010-03-06 - 2.7/3.2 beta 1 2010-04-03 - 2.7/3.2 beta 2 2010-05-01 - 2.7/3.2 rc1 2010-05-29 - 2.7/3.2 rc2 2010-06-12 - 2.7/3.2 final 2010-06-26
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. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Tue, Nov 10, 2009 at 5:13 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Arfrever Frehtes Taifersar Arahesis wrote:
2009-11-02 21:00 Benjamin Peterson <benjamin@python.org> napisał(a):
I've updated PEP 373 with my proposed release schedule:
- 2.7/3.2 alpha 1 2009-12-05 - 2.7/3.2 alpha 2 2010-01-09 - 2.7/3.2 alpha 3 2010-02-06 - 2.7/3.2 alpha 4 2010-03-06 - 2.7/3.2 beta 1 2010-04-03 - 2.7/3.2 beta 2 2010-05-01 - 2.7/3.2 rc1 2010-05-29 - 2.7/3.2 rc2 2010-06-12 - 2.7/3.2 final 2010-06-26
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.
Was this discussed somewhere? When I agreed to an early 3.1 release (or did I propose it?) I'm quite sure that I expected 3.2 to come the usual time (i.e., 18-24 months) after 3.1. I think I said something to the extent of "we'll treat 3.1 the same way we treat any release" which IMO implies a lifetime of 18-24 months. -- --Guido van Rossum (python.org/~guido)
On Tue, Nov 10, 2009 at 8:09 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Guido van Rossum <guido <at> python.org> writes:
Was this discussed somewhere?
I don't remember so, except for a short subthread on python-ideas where you indeed mentioned (to my disappointment :-)) that you were against a one-year release period.
Trust me on this too, please. We used to have releases once a year and we got really big serious feedback from our biggest users that the release cycle was going too fast. We discussed it amply and agreed on a minimum time of 18 months between releases. This was quite a while ago (I recall it being somewhere between 2000 and 2004) but I don't see that the situation has really changed -- if anything, we need to slow down more. We should really have a PEP for this, like we do for bugfix releases (PEP 6), but at the time we weren't so anal about PEPs for process. I realize this can be frustrating for developers who want to see their code released. I had the same feeling at the time. But when it was explained to me what a version upgrade looks like for a typical large company who have 100,000 or more lines of Python, often with insufficient tests, written by people who no longer work for the company or expensive consultants, I realized that releasing once a year was a break-neck pace for such users. There was wide discussion and community agreement on the 18 months minimum, as a compromise between the needs of large users (who would have been happier with two years) and the desires of developers (who, like you, preferred shorter release cycles). I really don't think we should change this "contract with our users" now. If necessary, we'll have to write a PEP to describe and explain it. -- --Guido van Rossum (python.org/~guido)
[Guido van Rossum]
. We used to have releases once a year and we got really big serious feedback from our biggest users that the release cycle was going too fast. We discussed it amply and agreed on a minimum time of 18 months between releases.
If the language moratorium goes into effect, would shorter release cycles still have a negative impact? Do people possibly want slower changes to the language and faster updates to the library? I don't know the answer. Just asking how this matches up with the feedback you have gotten previously. Raymond
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Raymond Hettinger wrote:
[Guido van Rossum]
. We used to have releases once a year and we got really big serious feedback from our biggest users that the release cycle was going too fast. We discussed it amply and agreed on a minimum time of 18 months between releases.
If the language moratorium goes into effect, would shorter release cycles still have a negative impact? Do people possibly want slower changes to the language and faster updates to the library?
I don't know the answer. Just asking how this matches up with the feedback you have gotten previously.
Depends on the kind of changes you are talking about: backward- incompatible ones (like the hashlib / medusa ones in 2.6, for instance) are likely going to be unpopular with the "Python with a tie" crowd (I think that was the name of the IPC BoF from which the original feedback coalesced). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkr5tC0ACgkQ+gerLs4ltQ4QzQCg1eUsdnAEyIficxjeFQevR9ul pv0An2qpDswkGhqAHkM2REtGE9Zpz8+V =t5kK -----END PGP SIGNATURE-----
On Tue, Nov 10, 2009 at 10:26 AM, Raymond Hettinger <python@rcn.com> wrote:
[Guido van Rossum]
. We used to have releases once a year and we got really big serious feedback from our biggest users that the release cycle was going too fast. We discussed it amply and agreed on a minimum time of 18 months between releases.
If the language moratorium goes into effect,
"If"? It's already Approved. :-)
would shorter release cycles still have a negative impact? Do people possibly want slower changes to the language and faster updates to the library?
I don't know the answer. Just asking how this matches up with the feedback you have gotten previously.
I expect it wouldn't make a difference since backwards compatibility testing involves a lot more than language syntax. -- --Guido van Rossum (python.org/~guido)
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
Martin v. Löwis wrote:
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 ---------------------------------------------------------------
2009/11/10 "Martin v. Löwis" <martin@v.loewis.de>:
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
Benjamin Peterson wrote:
2009/11/10 "Martin v. Löwis" <martin@v.loewis.de>:
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
[MvL]
I personally think that decoupling the releases would be best, i.e. not start thinking about 3.2 for another 6 months.
[Benjamin]
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.
My preference is to decouple and let 2.7 go out 18 months after 2.6. In general, 2.x users should not have to pay a price for whatever we do with 3.x. Raymond
Raymond Hettinger wrote:
[MvL]
I personally think that decoupling the releases would be best, i.e. not start thinking about 3.2 for another 6 months.
[Benjamin]
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.
My preference is to decouple and let 2.7 go out 18 months after 2.6. In general, 2.x users should not have to pay a price for whatever we do with 3.x.
And I guess anyone doing forward ports is likely going to be maintaining 2.6 compatibility anyway, so waiting until 3.2 comes out before using new 2.7 features wouldn't be a major burden. I think I've decided I don't mind either way, so I'm fine with whichever approach is easier for Benjamin and the platform installer builders to manage. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
participants (8)
-
"Martin v. Löwis" -
Antoine Pitrou -
Arfrever Frehtes Taifersar Arahesis -
Benjamin Peterson -
Guido van Rossum -
Nick Coghlan -
Raymond Hettinger -
Tres Seaver