3.3 branch created in main repository
Hi all,
from now on there is a 3.3 branch in the main repo.
Until the last ordinary 3.2 bugfix release is done (which will be soon), the usual procedure for 3.x will be to check into 3.2, merge into 3.3, and then merge into default, except of course for a) fixes of 3.3-only features and b) trivial things like typos that you don't feel have to be in 3.2.4.
default is now Python 3.4, and new features can be committed there.
When the binaries are built and all the fiddling with the web servers is done, I'll announce the 3.3.0 release, and then go drink a large quantity of champagne [1].
cheers, Georg
[1] If only I could afford it :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29/09/12 10:35, Georg Brandl wrote:
Until the last ordinary 3.2 bugfix release is done (which will be soon), the usual procedure for 3.x will be to check into 3.2, merge into 3.3, and then merge into default, except of course for a) fixes of 3.3-only features and b) trivial things like typos that you don't feel have to be in 3.2.4.
default is now Python 3.4, and new features can be committed there.
So, if I understand correctly, the current situation is this:
2.6: Security fixes only 2.7, 3.2, 3.3: Bugfixes only 2.3, 2.4, 2.5, 3.0, 3.1: Dead
After 3.2.4 is published ("soon"), 3.2 would move to "security fixes only". Am I right?
I wonder if we have a deadline for supporting 2.6 yet. How about 2.7?.
Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
On 9/30/2012 10:29 PM, Jesus Cea wrote:
So, if I understand correctly, the current situation is this:
2.6: Security fixes only 2.7, 3.2, 3.3: Bugfixes only 2.3, 2.4, 2.5, 3.0, 3.1: Dead
After 3.2.4 is published ("soon"), 3.2 would move to "security fixes only". Am I right?
I wonder if we have a deadline for supporting 2.6 yet. How about 2.7?.
Is there a PEP with end-of-life info?
Is there a PEP with end-of-life info?
I had meant to write a PEP on security releases for several years now. Since this still doesn't exist, here is the outline of the procedures that maintainers have agreed upon:
- bug fix releases are made until the next feature release is out (with 2.7 being an exception from that rule)
- security fixes are being provided until 5 years after the initial
release of the feature release
- for 2.6, this will be until Oct 1, 2013
- for 3.1, this will be until July 27, 2014
- for 3.2, this will be until Feb 20, 2016
- security releases are made whenever maintainers deem it necessary;
the two options are
- commit fixes into source repository only, and release whenever enough time has passed, or enough changes have accumulated, or
- release right after a security issue has been resolved
I'm not aware of a formal policy for 2.7. I guess it will end its life by BDFL pronouncement; giving it a 5 year bug fix period (which would end on July 3, 2015) seems a bit long to me - I'd favor to stop bug fixing along with the 3.4 release. The last BDFL decision (that I'm aware of) is that 2.7 should be supported "indefinitely", which is not "infinitely".
Regards, Martin
On 10/01/2012 01:30 PM, "Martin v. Löwis" wrote:
Is there a PEP with end-of-life info?
I had meant to write a PEP on security releases for several years now. Since this still doesn't exist, here is the outline of the procedures that maintainers have agreed upon:
- bug fix releases are made until the next feature release is out (with 2.7 being an exception from that rule)
- security fixes are being provided until 5 years after the initial release of the feature release
The 5 years horizon is based on requests of system packagers (Linux distributions in particular), who often also have 5-year cycles for long-term support.
- for 2.6, this will be until Oct 1, 2013
- for 3.1, this will be until July 27, 2014
- for 3.2, this will be until Feb 20, 2016
- security releases are made whenever maintainers deem it necessary; the two options are
Which of these to take depends on the nature of the fix, of course. The former is intended for system packagers of Python - they can incorporate fixes that are official already despite not having been released yet.
- commit fixes into source repository only, and release whenever enough time has passed, or enough changes have accumulated, or
- release right after a security issue has been resolved
I'm not aware of a formal policy for 2.7. I guess it will end its life by BDFL pronouncement; giving it a 5 year bug fix period (which would end on July 3, 2015) seems a bit long to me - I'd favor to stop bug fixing along with the 3.4 release. The last BDFL decision (that I'm aware of) is that 2.7 should be supported "indefinitely", which is not "infinitely".
I've now added lifespan information to the 3.2 and 3.3 release schedule PEPs, perhaps Barry and Benjamin could do the same for 2.6 to 3.1.
Georg
On Oct 01, 2012, at 02:23 PM, Georg Brandl wrote:
I've now added lifespan information to the 3.2 and 3.3 release schedule PEPs, perhaps Barry and Benjamin could do the same for 2.6 to 3.1.
Done for PEP 361, which actually covers both the 2.6 and 3.0 releases. I've described Python 3.0 as not being maintained for any purpose.
Cheers, -Barry
On 10/1/2012 8:23 AM, Georg Brandl wrote:
On 10/01/2012 01:30 PM, "Martin v. Löwis" wrote:
Is there a PEP with end-of-life info?
I had meant to write a PEP on security releases for several years now. Since this still doesn't exist, here is the outline of the procedures that maintainers have agreed upon:
- bug fix releases are made until the next feature release is out (with 2.7 being an exception from that rule)
- security fixes are being provided until 5 years after the initial release of the feature release
The 5 years horizon is based on requests of system packagers (Linux distributions in particular), who often also have 5-year cycles for long-term support.
- for 2.6, this will be until Oct 1, 2013
- for 3.1, this will be until July 27, 2014
- for 3.2, this will be until Feb 20, 2016
- security releases are made whenever maintainers deem it necessary; the two options are
Which of these to take depends on the nature of the fix, of course. The former is intended for system packagers of Python - they can incorporate fixes that are official already despite not having been released yet.
- commit fixes into source repository only, and release whenever enough time has passed, or enough changes have accumulated, or
- release right after a security issue has been resolved
I'm not aware of a formal policy for 2.7. I guess it will end its life by BDFL pronouncement; giving it a 5 year bug fix period (which would end on July 3, 2015) seems a bit long to me - I'd favor to stop bug fixing along with the 3.4 release. The last BDFL decision (that I'm aware of) is that 2.7 should be supported "indefinitely", which is not "infinitely".
I've now added lifespan information to the 3.2 and 3.3 release schedule PEPs, perhaps Barry and Benjamin could do the same for 2.6 to 3.1.
Someone recently said they could not find life-cycle information on python.org. I think it would be good to have one PEP or website page that has the general policy, given above by Martin, the exception for 2.7, and a summary table with one line per release (back to say, 2.5), giving number and date for
Initial release Last bug fix release Last security release ... 3.3.0 2012 Sep 30 (2014 ???) (2017 Sep)
(tentative dates in parens)
Terry
2012/10/1 Georg Brandl g.brandl@gmx.net:
I've now added lifespan information to the 3.2 and 3.3 release schedule PEPs, perhaps Barry and Benjamin could do the same for 2.6 to 3.1.
I just updated the 3.1 and 2.7 schedules.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/10/12 14:23, Georg Brandl wrote:
I've now added lifespan information to the 3.2 and 3.3 release schedule PEPs, perhaps Barry and Benjamin could do the same for 2.6 to 3.1.
http://python.org/dev/peps/pep-0398/
""" 3.3 Lifespan
3.3 will receive bugfix updates approximately every 4-6 months until one release after the release of 3.4.0 final. After that, security updates (source only) will be released until 5 years after the release of 3.3.0 final, which will be September 2017. """
I am not a native english speaker, but I guess the intention is to do a final bugfix release for 3.3 after 3.4.0 is out, before moving 3.3 to "security fixes only". Could you possibly clarify the wording in the PEP?.
Sorry if I am being a pain :).
Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
On Tue, 02 Oct 2012 01:41:25 +0200, Jesus Cea jcea@jcea.es wrote:
On 01/10/12 14:23, Georg Brandl wrote:
I've now added lifespan information to the 3.2 and 3.3 release schedule PEPs, perhaps Barry and Benjamin could do the same for 2.6 to 3.1.
http://python.org/dev/peps/pep-0398/
""" 3.3 Lifespan
3.3 will receive bugfix updates approximately every 4-6 months until one release after the release of 3.4.0 final. After that, security updates (source only) will be released until 5 years after the release of 3.3.0 final, which will be September 2017. """
I am not a native english speaker, but I guess the intention is to do a final bugfix release for 3.3 after 3.4.0 is out, before moving 3.3 to "security fixes only". Could you possibly clarify the wording in the PEP?.
As a native English speaker it is not immediately obvious to me how to make that clearer. Is it that the antecedent of "one release" isn't clear?
--David
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/12 02:25, R. David Murray wrote:
3.3 will receive bugfix updates approximately every 4-6 months until one release after the release of 3.4.0 final. After that, security
[...]
As a native English speaker it is not immediately obvious to me how to make that clearer. Is it that the antecedent of "one release" isn't clear?
I naivelly interpret "until one release after the release of 3.4.0" as talking about doing another 3.4 release. I find it ambiguous about what branch we are talking about.
Maybe something in the line of "the last bugfix release of 3.3 will be done after 3.4.0 is published". Or "After 3.4.0 is released, we will release a final bugfix release of 3.3".
Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
On 10/02/2012 02:37 AM, Jesus Cea wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/12 02:25, R. David Murray wrote:
3.3 will receive bugfix updates approximately every 4-6 months until one release after the release of 3.4.0 final. After that, security
[...]
As a native English speaker it is not immediately obvious to me how to make that clearer. Is it that the antecedent of "one release" isn't clear?
I naivelly interpret "until one release after the release of 3.4.0" as talking about doing another 3.4 release. I find it ambiguous about what branch we are talking about.
Maybe something in the line of "the last bugfix release of 3.3 will be done after 3.4.0 is published". Or "After 3.4.0 is released, we will release a final bugfix release of 3.3".
I've tried to reword it now.
Georg
On 10/1/2012 8:37 PM, Jesus Cea wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/12 02:25, R. David Murray wrote:
3.3 will receive bugfix updates approximately every 4-6 months until one release after the release of 3.4.0 final.
This is a bit weird, as it can be read as implying after 3.4.1.
I naivelly interpret "until one release after the release of 3.4.0" as talking about doing another 3.4 release. I find it ambiguous about what branch we are talking about.
Maybe something in the line of "the last bugfix release of 3.3 will be done after 3.4.0 is published". Or "After 3.4.0 is released, we will release a final bugfix release of 3.3".
3.3 will receive bugfix updates approximately every 4-6 months until the final bugfix release soon after the release of 3.4.0.
Is that clearer?
tjr
Le lundi 01 octobre 2012 à 13:30 +0200, "Martin v. Löwis" a écrit :
I'm not aware of a formal policy for 2.7. I guess it will end its life by BDFL pronouncement; giving it a 5 year bug fix period (which would end on July 3, 2015) seems a bit long to me - I'd favor to stop bug fixing along with the 3.4 release.
"5 years" was once recorded in the 2.7 release page: http://mail.python.org/pipermail/python-list/2010-April/573621.html
... although it isn't anymore: “Python 2.7 is scheduled to be the last major version in the 2.x series before it moves into an extended maintenance period.” http://www.python.org/download/releases/2.7/
Benjamin is the 2.7 release manager (good choice on his part ;-)), and on this thread he seems to be of the advice that 5 years is the number.
Perhaps we can relax the 2.7 bugfix policy a bit: bugfix releases are made for 5 years, but core developers are free not to port minor bugfixes if they want to save up some time.
Regards
Antoine.
On Oct 01, 2012, at 02:44 PM, Antoine Pitrou wrote:
"5 years" was once recorded in the 2.7 release page: http://mail.python.org/pipermail/python-list/2010-April/573621.html
... although it isn't anymore: “Python 2.7 is scheduled to be the last major version in the 2.x series before it moves into an extended maintenance period.” http://www.python.org/download/releases/2.7/
Benjamin is the 2.7 release manager (good choice on his part ;-)), and on this thread he seems to be of the advice that 5 years is the number.
Perhaps we can relax the 2.7 bugfix policy a bit: bugfix releases are made for 5 years, but core developers are free not to port minor bugfixes if they want to save up some time.
I think we should make a formal commitment to 2.7's lifespan, whatever that would be. When discussions about Python 2's ultimate demise come up, we should be able to point to the PEP for the official declaration, since once Python 2.7 maintenance ends, so does effectively Python 2's lifespan.
the-champagne-is-cooling-as-we-speak-ly y'rs, -Barry
On Oct 01, 2012, at 01:30 PM, Martin v. Löwis wrote:
I had meant to write a PEP on security releases for several years now.
+1
Since this still doesn't exist, here is the outline of the procedures that maintainers have agreed upon:
- bug fix releases are made until the next feature release is out (with 2.7 being an exception from that rule)
- security fixes are being provided until 5 years after the initial release of the feature release
The 5 years horizon is based on requests of system packagers (Linux distributions in particular), who often also have 5-year cycles for long-term support.
- for 2.6, this will be until Oct 1, 2013
- for 3.1, this will be until July 27, 2014
- for 3.2, this will be until Feb 20, 2016
- security releases are made whenever maintainers deem it necessary; the two options are
Which of these to take depends on the nature of the fix, of course. The former is intended for system packagers of Python - they can incorporate fixes that are official already despite not having been released yet.
- commit fixes into source repository only, and release whenever enough time has passed, or enough changes have accumulated, or
- release right after a security issue has been resolved
The only thing missing is whether releases are made source-only or with binary packages for Windows and Mac. My understanding is that once a release goes into security-only mode, binary releases cease.
Cheers, -Barry
2012/9/30 Jesus Cea jcea@jcea.es:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29/09/12 10:35, Georg Brandl wrote:
Until the last ordinary 3.2 bugfix release is done (which will be soon), the usual procedure for 3.x will be to check into 3.2, merge into 3.3, and then merge into default, except of course for a) fixes of 3.3-only features and b) trivial things like typos that you don't feel have to be in 3.2.4.
default is now Python 3.4, and new features can be committed there.
So, if I understand correctly, the current situation is this:
2.6: Security fixes only 2.7, 3.2, 3.3: Bugfixes only 2.3, 2.4, 2.5, 3.0, 3.1: Dead
3.1 still recieves security fixes.
After 3.2.4 is published ("soon"), 3.2 would move to "security fixes only". Am I right?
I wonder if we have a deadline for supporting 2.6 yet. How about 2.7?.
2.7 will get at least 5 years of support.
On 10/01/2012 04:29 AM, Jesus Cea wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29/09/12 10:35, Georg Brandl wrote:
Until the last ordinary 3.2 bugfix release is done (which will be soon), the usual procedure for 3.x will be to check into 3.2, merge into 3.3, and then merge into default, except of course for a) fixes of 3.3-only features and b) trivial things like typos that you don't feel have to be in 3.2.4.
default is now Python 3.4, and new features can be committed there.
So, if I understand correctly, the current situation is this:
2.6: Security fixes only 2.7, 3.2, 3.3: Bugfixes only 2.3, 2.4, 2.5, 3.0, 3.1: Dead
After 3.2.4 is published ("soon"), 3.2 would move to "security fixes only". Am I right?
Correct, except for 3.1 in the "security fixes" category.
You are right that we should have information about bugfix/security mode and about end-of-life; I propose to put them in the respective release schedule PEPs.
Georg
On 10/1/2012 1:02 AM, Georg Brandl wrote:
You are right that we should have information about bugfix/security mode and about end-of-life; I propose to put them in the respective release schedule PEPs.
From the commit:
+3.3 will receive bugfix updates approximately every 4-6 months until
+3.3.1 schedule +--------------
+- 3.3.1 beta 1: planned for Oct/Nov 2012
I presume you see a number of little fixes coming that should not too long. I almost missed this ;-).
Terry
On Mon, 01 Oct 2012 10:57:45 -0400, Terry Reedy tjreedy@udel.edu wrote:
On 10/1/2012 1:02 AM, Georg Brandl wrote:
You are right that we should have information about bugfix/security mode and about end-of-life; I propose to put them in the respective release schedule PEPs.
From the commit:
+3.3 will receive bugfix updates approximately every 4-6 months until
+3.3.1 schedule +--------------
+- 3.3.1 beta 1: planned for Oct/Nov 2012
I presume you see a number of little fixes coming that should not too long. I almost missed this ;-).
I believe Georg is basing this on past experience, both ours and the general software community...the users *always* find nasty bugs only after the first production release :)
I have some hope we did a little better this time, though. Judging by the bug reports we got a bunch of pre-testing from both the Gentoo team and Ubuntu, and I'm pretty sure their testing has been more extensive this time than it was for previous 3.x releases.
On the other hand, Gentoo (Arfrever) already found one crasher post-release...but fortunately it only happens in debug builds (although that could mean there is a behavior bug in non-debug builds).
--David
2012/10/1 R. David Murray rdmurray@bitdance.com:
On the other hand, Gentoo (Arfrever) already found one crasher post-release...but fortunately it only happens in debug builds (although that could mean there is a behavior bug in non-debug builds).
It definitely happens in release builds.
On 10/01/2012 07:30 PM, Benjamin Peterson wrote:
2012/10/1 R. David Murray rdmurray@bitdance.com:
On the other hand, Gentoo (Arfrever) already found one crasher post-release...but fortunately it only happens in debug builds (although that could mean there is a behavior bug in non-debug builds).
It definitely happens in release builds.
I guess you're talking about the *second* crasher :|
Georg
On 10/01/2012 04:57 PM, Terry Reedy wrote:
On 10/1/2012 1:02 AM, Georg Brandl wrote:
You are right that we should have information about bugfix/security mode and about end-of-life; I propose to put them in the respective release schedule PEPs.
From the commit:
+3.3 will receive bugfix updates approximately every 4-6 months until
+3.3.1 schedule +--------------
+- 3.3.1 beta 1: planned for Oct/Nov 2012
I presume you see a number of little fixes coming that should not too long. I almost missed this ;-).
No, in fact we have a security fix in the pipeline; the point releases for all branches will come out when the respective patch is finished.
That we can quickly fix not-so-critical but annoying bugs found by users in 3.3.0 is a nice side-effect.
cheers, Georg
So, if I understand correctly, the current situation is this:
2.6: Security fixes only 2.7, 3.2, 3.3: Bugfixes only 2.3, 2.4, 2.5, 3.0, 3.1: Dead
Would it be possible to write this status in the devguide (and also maintain it!)?
Victor
Am 02.10.12 11:47, schrieb Victor Stinner:
So, if I understand correctly, the current situation is this:
2.6: Security fixes only 2.7, 3.2, 3.3: Bugfixes only 2.3, 2.4, 2.5, 3.0, 3.1: Dead
Would it be possible to write this status in the devguide (and also maintain it!)?
Putting it there is surely possible. Keeping it maintained is absolutely impossible, if you expect an update to happen as part of the release process. The release process is already complex enough, so there shouldn't be any additional steps in the release process.
Instead, having people point out inconsistencies and them somebody fixing them is something that could work.
Regards, Martin
On 10/02/2012 11:47 AM, Victor Stinner wrote:
So, if I understand correctly, the current situation is this:
2.6: Security fixes only 2.7, 3.2, 3.3: Bugfixes only 2.3, 2.4, 2.5, 3.0, 3.1: Dead
Would it be possible to write this status in the devguide (and also maintain it!)?
I would support putting links to the release schedule PEPs in the devguide somewhere.
Georg
participants (9)
-
"Martin v. Löwis" -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Georg Brandl -
Jesus Cea -
R. David Murray -
Terry Reedy -
Victor Stinner