What's New text on future maintenance
FYI: I've just added the text below to the "What's New" document for 2.7. I wanted to describe how 2.7 will probably be maintained, but didn't want to write anything that sounded like an iron-clad guarantee of a maintenance timespan. Does this text seem like a reasonable set of statements? --amk Python 2.7 is intended to be the last major release in the 2.x series. Though more major releases have not been absolutely ruled out, the Python maintainers are planning to focus their efforts on Python 3.x. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are: * It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x is in progress, and that transition will itself be lengthy. Most 2.x versions are maintained for about 4 years, from the first to the last bugfix release; patchlevel releases for Python 2.7 will probably be made for at least 6 years. * Because 2.7 will be running production applications, a policy decision was made to silence warnings only of interest to developers by default. Silencing :exc:`DeprecationWarning` and its descendants prevents users from seeing warnings triggered by an application. (Carried out in :issue:`7319`.) You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault` (short form: :option:`-Wd`) switch, or you can add ``warnings.simplefilter('default')`` to your code.
On Thu, May 6, 2010 at 6:50 PM, A.M. Kuchling
FYI: I've just added the text below to the "What's New" document for 2.7. I wanted to describe how 2.7 will probably be maintained, but didn't want to write anything that sounded like an iron-clad guarantee of a maintenance timespan. Does this text seem like a reasonable set of statements?
--amk
Python 2.7 is intended to be the last major release in the 2.x series. Though more major releases have not been absolutely ruled out, the
I would scrap the "Though more ... ruled out" part. That just stokes unrealistic hopes. :-)
Python maintainers are planning to focus their efforts on Python 3.x.
This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are:
* It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x is in progress, and that transition will itself be lengthy. Most 2.x versions are maintained for about 4 years, from the first to the last bugfix release; patchlevel releases for Python 2.7 will probably be made for at least 6 years.
* Because 2.7 will be running production applications, a policy decision was made to silence warnings only of interest to developers by default. Silencing :exc:`DeprecationWarning` and its descendants prevents users from seeing warnings triggered by an application. (Carried out in :issue:`7319`.)
You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault` (short form: :option:`-Wd`) switch, or you can add ``warnings.simplefilter('default')`` to your code.
All this sounds fine to me. Thanks for taking the time to write this! -- --Guido van Rossum (python.org/~guido)
"A.M. Kuchling"
FYI: I've just added the text below to the "What's New" document for 2.7. I wanted to describe how 2.7 will probably be maintained, but didn't want to write anything that sounded like an iron-clad guarantee of a maintenance timespan. Does this text seem like a reasonable set of statements?
If you give an actual time period, that's all that will actually be communicated to most people. This text will be read by a few people, and communicated as simply “six years” to everyone else. It doesn't matter how many caveats and qualifiers you surround that with; those will all be lost in transmission from person to person. Would it make more sense to, instead of giving a time period, rather describe the *circumstances* that will determine when maintenance releases will cease for 2.7? -- \ “Religious faith is the one species of human ignorance that | `\ will not admit of even the *possibility* of correction.” —Sam | _o__) Harris, _The End of Faith_, 2004 | Ben Finney
2010/5/6 A.M. Kuchling
FYI: I've just added the text below to the "What's New" document for 2.7. I wanted to describe how 2.7 will probably be maintained, but didn't want to write anything that sounded like an iron-clad guarantee of a maintenance timespan. Does this text seem like a reasonable set of statements?
--amk
Python 2.7 is intended to be the last major release in the 2.x series. Though more major releases have not been absolutely ruled out, the Python maintainers are planning to focus their efforts on Python 3.x.
This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are:
* It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x is in progress, and that transition will itself be lengthy. Most 2.x versions are maintained for about 4 years, from the first to the last bugfix release; patchlevel releases for Python 2.7 will probably be made for at least 6 years.
I don't think there's any point in being hypothetical about. I believe we've already said that maintence for 2.7 will last for at least 5 years, so let's proclaim it. -- Regards, Benjamin
On May 06, 2010, at 09:33 PM, Benjamin Peterson wrote:
I don't think there's any point in being hypothetical about. I believe we've already said that maintence for 2.7 will last for at least 5 years, so let's proclaim it.
+1. If our goal is to move our community to Python 3, then I think we do them the biggest service to be explicit about our intentions for maintenance of 2.7 and the future of Python 2. -Barry
On 5/6/2010 9:50 PM, A.M. Kuchling wrote:
FYI: I've just added the text below to the "What's New" document for 2.7. I wanted to describe how 2.7 will probably be maintained, but didn't want to write anything that sounded like an iron-clad guarantee of a maintenance timespan. Does this text seem like a reasonable set of statements?
--amk
Python 2.7 is intended to be the last major release in the 2.x series. Though more major releases have not been absolutely ruled out, the Python maintainers are planning to focus their efforts on Python 3.x.
This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Two consequences of the long-term significance of 2.7 are:
* It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x is in progress, and that transition will itself be lengthy. Most 2.x versions are maintained for about 4 years, from the first to the last bugfix release; patchlevel releases for Python 2.7 will probably be made for at least 6 years.
Actually, bugfix releases generally stop with the next major release, with about a 2 year interval. I agree with others about condensing, to something like: "Python 2.7 is intended to be the last major release in the 2.x series. Python core developers plan to focus future efforts on Python 3.x. This means that 2.7 will remain in place for a long time, running production systems that have not been ported to Python 3.x. Bugfix releases will likely continue for 5 years." Then the warnings stuff
* Because 2.7 will be running production applications, a policy
Every major version (xcept 3.0) has run production application, and 3.1 may be and 3.2 certainly will be. So this reasoning is not clear to me.
decision was made to silence warnings only of interest to developers by default.
I believe this is meant to say "Warnings aimed only at those porting code to 3.x are silenced by default."
Silencing :exc:`DeprecationWarning` and its descendants prevents users from seeing warnings triggered by an application. (Carried out in :issue:`7319`.)
You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault` (short form: :option:`-Wd`) switch, or you can add ``warnings.simplefilter('default')`` to your code.
Terry Jan Reedy
Terry Reedy wrote:
Then the warnings stuff
* Because 2.7 will be running production applications, a policy
Every major version (xcept 3.0) has run production application, and 3.1 may be and 3.2 certainly will be. So this reasoning is not clear to me.
decision was made to silence warnings only of interest to developers by default.
I believe this is meant to say "Warnings aimed only at those porting code to 3.x are silenced by default."
Actually, the decision was indeed to make all Deprecation Warnings silent by default. The rationale was a bit different from what AMK currently has though (otherwise we wouldn't have made the same change in 3.x). I'll take a stab at a more accurate rationale: """For previous releases, it has been the policy of the CPython core developers that :exc:`DeprecationWarning` should be enabled by default. This provides Python developers with a clear indication when their code has a substantial risk of breaking in the next major version of Python. However, the nature of Python usage has changed over the years, such that there are now a significantly larger number of Python application users that are not directly involved in the development of those applications. This has lead to a situation where users may be receiving irrelevant warnings from an application that is actually working correctly, creating unnecessary concern for affected end users and additional overhead for the developers of these applications in responding to these concerns. Accordingly, starting with Python 2.7, this policy has been revised and the CPython interpreter has been updated to silence all occurrences of :exc:`DeprecationWarning` by default. Developers wishing to see if their application is at significant risk of breaking on the next major Python release can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault` (short form: :option:`-Wd`) switch, or you can add ``warnings.simplefilter('default')`` to your code. (Note that the 'default' in these settings refers to the default warning behaviour of displaying warnings once for each location where they are encountered rather than to the overall default warning settings used by the interpreter)""" Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Fri, May 07, 2010 at 07:52:49PM +1000, Nick Coghlan wrote:
3.x). I'll take a stab at a more accurate rationale:
Thanks! I've applied the scalpel and reduced it to: * A policy decision was made to silence warnings only of interest to developers by default. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. (Carried out in :issue:`7319`.) In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python. However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening the developers of these applications with responding to these concerns. You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault` (short form: :option:`-Wd`) switch, or you can add ``warnings.simplefilter('default')`` to your code. Benjamin suggested being very definite about a 5-year maintenance period, but I don't want to write any checks our butt can't cash, so I've left the text as "Maintenance releases for Python 2.7 will probably be made for 5 years." An alternative formulation might say it will be maintained for the next two 3.x releases, not the next one as usual. I thought about Ben Finney's suggestion to not give a timespan and describe the conditions for 2.x maintenance continuing, but those conditions are complicated to describe -- if 3.x doesn't catch on? if the 3.x transition is slow? if there's a significant 2.x user base that remains? if someone starts a 2.x maintenance team? -- and might be a confusing tangle of what-if statements. --amk
On Fri, May 7, 2010 at 09:09, A.M. Kuchling
On Fri, May 07, 2010 at 07:52:49PM +1000, Nick Coghlan wrote:
3.x). I'll take a stab at a more accurate rationale:
Thanks! I've applied the scalpel and reduced it to:
* A policy decision was made to silence warnings only of interest to developers by default. :exc:`DeprecationWarning` and its descendants are now ignored unless otherwise requested, preventing users from seeing warnings triggered by an application. (Carried out in :issue:`7319`.)
In previous releases, :exc:`DeprecationWarning` messages were enabled by default, providing Python developers with a clear indication of where their code may break in a future major version of Python.
However, there are increasingly many users of Python-based applications who are not directly involved in the development of those applications. :exc:`DeprecationWarning` messages are irrelevant to such users, making them worry about an application that's actually working correctly and burdening the developers of these applications with responding to these concerns.
You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault` (short form: :option:`-Wd`) switch, or you can add ``warnings.simplefilter('default')`` to your code.
That sounds good to me.
Benjamin suggested being very definite about a 5-year maintenance period, but I don't want to write any checks our butt can't cash, so I've left the text as "Maintenance releases for Python 2.7 will probably be made for 5 years." An alternative formulation might say it will be maintained for the next two 3.x releases, not the next one as usual.
I thought about Ben Finney's suggestion to not give a timespan and describe the conditions for 2.x maintenance continuing, but those conditions are complicated to describe -- if 3.x doesn't catch on? if the 3.x transition is slow? if there's a significant 2.x user base that remains? if someone starts a 2.x maintenance team? -- and might be a confusing tangle of what-if statements.
Why can't we simply say that "we plan to support Python 2.7 beyond the typical two years for bugfix releases"? It doesn't tie us to anything but still lets people know our intentions. We don't have to worry about every possible scenario now (e.g. 3.x gets no more traction or some other rare event) and saying we plan on long term support but don't know for how long is completely truthful; we have no timeline on how long we are willing to keep 2.7 afloat beyond the fact that we plan to do it longer than normal.
On May 7, 2010, at 9:09 AM, A.M. Kuchling wrote:
You can re-enable display of :exc:`DeprecationWarning` messages by running Python with the :option:`-Wdefault` (short form: :option:`-Wd`) switch, or you can add ``warnings.simplefilter('default')`` to your code.
The new PYTHONWARNINGS env var also needs mentioning here, how's about: You can re-enable display of :exc:`DeprecationWarning` messages by either running Python with the :option:`-Wdefault` (short form: :option:`-Wd`) switch or by setting the :envvar:`PYTHONWARNINGS` environment variable to "default" (or "d") before running Python. Python code can also re-enable them by calling ``warnings.simplefilter('default')``. -- Philip Jenvey
A.M. Kuchling wrote:
On Fri, May 07, 2010 at 07:52:49PM +1000, Nick Coghlan wrote:
3.x). I'll take a stab at a more accurate rationale:
Thanks! I've applied the scalpel and reduced it to:
I saw this go by on the checkin list - looks good (although Philip is right about mentioning PYTHONWARNINGS). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
* It's very likely the 2.7 release will have a longer period of maintenance compared to earlier 2.x versions. Python 2.7 will continue to be maintained while the transition to 3.x is in progress, and that transition will itself be lengthy. Most 2.x versions are maintained for about 4 years, from the first to the last bugfix release; patchlevel releases for Python 2.7 will probably be made for at least 6 years.
I agree with Terry: how did you arrive at the 4 years for 2.x releases? Bug fixes releases stopped after the next feature release being made, which gave (counting between initial release and last bug fix release): - 2.0 9 months - 2.1 12 months - 2.2 17 months - 2.3 19 months - 2.4 22 months - 2.5 27 months - 2.6 < 22 months (assuming the final 2.6 release is made before August) In addition, since 2.3, we were offering security fixes for a period of _five_ years. So for 2.7, the question really is how long we create bug fix releases and Windows binaries, rather than accepting only security fixes, and producing source-only releases. I'd personally expect that "longer" might mean 3 years (i.e. one more release cycle), and definitely less than 6. Regards, Martin
On Fri, May 07, 2010 at 09:30:00AM +0200, "Martin v. Löwis" wrote:
I agree with Terry: how did you arrive at the 4 years for 2.x releases? Bug fixes releases stopped after the next feature release being made, which gave (counting between initial release and last bug fix release):
I used the initial release date of 2.4 and 2.5 and the dates of the last patchlevel releases. That may well be distorted by the recent spasm of activity that led to 2.5.4. --amk
A.M. Kuchling wrote:
On Fri, May 07, 2010 at 09:30:00AM +0200, "Martin v. Löwis" wrote:
I agree with Terry: how did you arrive at the 4 years for 2.x releases? Bug fixes releases stopped after the next feature release being made, which gave (counting between initial release and last bug fix release):
I used the initial release date of 2.4 and 2.5 and the dates of the last patchlevel releases. That may well be distorted by the recent spasm of activity that led to 2.5.4.
Ah. But the most recent 2.4 and 2.5 patchlevel releases are *not* bugfix releases. They only provide security fixes, and I plan to provide them for a period of five years (after the initial release). Regards, Martin
participants (10)
-
"Martin v. Löwis" -
A.M. Kuchling -
Barry Warsaw -
Ben Finney -
Benjamin Peterson -
Brett Cannon -
Guido van Rossum -
Nick Coghlan -
Philip Jenvey -
Terry Reedy