-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 10, 2007, at 6:46 PM, Martin v. Löwis wrote:

...

"The Python Software Foundation officially supports the current stable major release and one prior major release. Currently, Python 2.5 and 2.4 are officially supported.

If you take "officially supported" to mean "there will be further bugfix releases", then no: 2.4 is not anymore officially supported. Only 2.5 is officially supported. There may, of course, be security patches released for 2.4 if there is a need.

Is this draft any better? "The Python Software Foundation officially supports the current stable major release of Python. By "supports" we mean that the PSF will produce bug fix releases of this version, currently Python 2.5. We may release patches for earlier versions if necessary, such as to fix security problems, but we generally do not make releases of such unsupported versions. Patch releases of earlier Python versions may be made available through third parties, including OS vendors." - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkTraHEjvBPtnXfVAQLsZAP/eOCIn77Z+wfbdX0ys8N1LWCd242alW/p 6ws9qa6BQ2At5tDBAZtwjR2QX8LKn4zlM2CgaqvVrEjvZ8hgtSDv4hC0jfa0YCHQ bUrNzu3pZfJm62S0SFs753jtcImRFwBMBHHBU47N6GqXOB+mAlMgvAtch3Zakidq 37by4Iefj84= =28A4 -----END PGP SIGNATURE-----

At 12:58 AM +0200 5/12/07, Martin v. Löwis wrote:

...

"The Python Software Foundation officially supports the current stable major release of Python. By "supports" we mean that the PSF will produce bug fix releases of this version, currently Python 2.5. We may release patches for earlier versions if necessary, such as to fix security problems, but we generally do not make releases of such unsupported versions. Patch releases of earlier Python versions may be made available through third parties, including OS vendors."

If such an official statement still can be superseded by an even more official PEP, it's fine with me.

However, I would prefer to not use the verb "support" at all. We (the PSF) don't provide any technical support for *any* version ever released: '''PSF is making Python available to Licensee on an "AS IS" basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT INFRINGE ANY THIRD PARTY RIGHTS.'''

The more I think about it: no, there is no official support for the current stable release. We will like produce more bug fix releases, but then, we may not if the volunteers doing so lose time or interest, and 2.6 comes out earlier than planned.

Why do you need such a statement?

I think Fedora might want it, per recent discussions on fedora-devel-list. My impertinent attempt: "The Python Software Foundation maintains the current stable major release of Python. By "maintains" we mean that the PSF will produce bug fix releases of that version, currently Python 2.5. We have released patches for earlier versions as necessary, such as to fix security problems, but we generally do not make releases of such prior versions. Patched releases of earlier Python versions may be made available through third parties, including OS vendors." -- ____________________________________________________________________ TonyN.:' mailto:tonynelson@georgeanelson.com ' http://www.georgeanelson.com/

On Saturday 12 May 2007, skip@pobox.com wrote:

Since there is (generally?) an attempt to make one last bug fix release of the previous version after the next major version is released, should that be mentioned? To make it concrete, I believe shortly after 2.5.0 was released the final bug fix release of 2.4 (2.4.4?) was released.

Correct. Note that this is only something that's been in place while I've been doing it. The current "standard" for how we do releases is just something I made up as I went along, including - regular 6-monthly bugfix releases - only one maintenance branch (most recent) for the bugfix releases - the last bugfix release of the previous release after a new major release. I'm OK with these being formalised - but any additional requirements I'd like to discuss first :-) Anthony -- Anthony Baxter It's never too late to have a happy childhood.

Terry Reedy writes:

This strikes me as an improvement, but 'maintain' is close to 'support' and seems to make a promise that might also have unintended legal consequences. But that is what your legal consel is for.

Unilateral statements on a web page do not constitute a contract. Implied warrantees *are* a problem, but those are taken care of by the license. (IANAL, etc.) What's left is purely an issue of marketing, ie, to real people a promise is a promise whether legally enforced or not. No matter how weaselly the wording on the website, users expect support and deprecate projects that don't provide it. And in Python practice they get it, and will continue calling it "support". Unless there are real legal consequences, I think it's a good idea for the PSF to define explicitly how the resources it either controls or can elicit from volunteers will be used, to the extent that PSF can do so. And it's best if the words "support" and "maintain" are used, because that's how the users think about it.

'Official' statements need both motivation (what is there that is actually broken?)

The impression that many people (including python-dev regulars) have that there is a "policy" of "support" for both the current release (2.5) and the (still very widely used) previous release (2.4) is a real problem, and needs to be addressed.

Terry Reedy writes:

"Stephen J. Turnbull" wrote in message news:17989.27755.568352.465481@uwakimon.sk.tsukuba.ac.jp... | The impression that many people (including python-dev regulars) have | that there is a "policy" of "support" for both the current release | (2.5) and the (still very widely used) previous release (2.4) is a | real problem, and needs to be addressed.

I agree that such mis-understanding should be addressed. So I now think a paragraph summarizing Martin's info PEP, ending with "For details, see PEPxxx.", would be a good idea.

FWIW, after Martin's explanation, and considering the annoyance of keeping updates sync'ed (can PEPs be amended after acceptance, or only superseded by a new PEP, like IETF RFCs?), I tend to support Barry's suggestion of a brief listing of current releases and next planned, and "Python policy concerning release planning is defined by [the current version of] PEPxxx", with a link.

Stephen J. Turnbull wrote:

Terry Reedy writes:

...

"Stephen J. Turnbull" wrote in message news:17989.27755.568352.465481@uwakimon.sk.tsukuba.ac.jp... | The impression that many people (including python-dev regulars) have | that there is a "policy" of "support" for both the current release | (2.5) and the (still very widely used) previous release (2.4) is a | real problem, and needs to be addressed.

...

I agree that such mis-understanding should be addressed. So I now think a paragraph summarizing Martin's info PEP, ending with "For details, see PEPxxx.", would be a good idea.

FWIW, after Martin's explanation, and considering the annoyance of keeping updates sync'ed (can PEPs be amended after acceptance, or only superseded by a new PEP, like IETF RFCs?), I tend to support Barry's suggestion of a brief listing of current releases and next planned, and "Python policy concerning release planning is defined by [the current version of] PEPxxx", with a link.

In which case doesn't it make more sense to use the existing mechanism of PEP 356 (Release Schedule)? If something isn't listed in there (even without dates) then there are no current plans to release it, and that tells the reader everything they need to know. At the moment the PEP begins with "This document describes the development and release schedule for Python 2.5." but it could just as easily say "future releases of the Python 2.X series" or something similar. Which reminds me, that PEP needs updating! regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden ------------------ Asciimercial --------------------- Get on the web: Blog, lens and tag your way to fame!! holdenweb.blogspot.com squidoo.com/pythonology tagged items: del.icio.us/steve.holden/python All these services currently offer free registration! -------------- Thank You for Reading ----------------

Nick Coghlan wrote:

Steve Holden wrote:

...

In which case doesn't it make more sense to use the existing mechanism of PEP 356 (Release Schedule)? If something isn't listed in there (even without dates) then there are no current plans to release it, and that tells the reader everything they need to know.

At the moment the PEP begins with "This document describes the development and release schedule for Python 2.5." but it could just as easily say "future releases of the Python 2.X series" or something similar.

Which reminds me, that PEP needs updating!

Those release schedule PEPs are mainly a TODO list leading up to the 2.x.0 releases, though - there's a new one for each major version bump:

PEP 160 - Python 1.6 PEP 200 - Python 2.0 PEP 226 - Python 2.1 PEP 251 - Python 2.2 PEP 283 - Python 2.3 PEP 320 - Python 2.4 PEP 356 - Python 2.5 PEP 361 - Python 2.6

Cheers, Nick.

Thanks, it wouldn't be appropriate then (and 361 *doesn't* need updating). regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden ------------------ Asciimercial --------------------- Get on the web: Blog, lens and tag your way to fame!! holdenweb.blogspot.com squidoo.com/pythonology tagged items: del.icio.us/steve.holden/python All these services currently offer free registration! -------------- Thank You for Reading ----------------

"Martin v. Löwis" writes:

However, I would prefer to not use the verb "support" at all. We (the PSF) don't provide any technical support for *any* version ever released: '''PSF is making Python available to Licensee on an "AS IS" basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES [...].'''

Of course the PSF provides *excellent* technical support; you just don't acknowledge any *obligation* to do it. A declaration of support is not a warranty, of course. So I see no problem with using the word "support". You may wish to clarify with terms like "resources available".

Why do you need such a statement?

Because it expresses what IMO *actually happens* clearly, and clarifies the intent of the PSF to continue in the same way. This is useful to users making decisions, even though the PSF owns few to none of the resources needed. The generosity of the contributors and their loyalty to Python and to each other practically guarantees availability. Python can dispose of a raft of bugs present only in the older versions with WONTFIX at release of a new stable version (after double-checking that they don't exist in the stable version). Developers can respond to reports of bugs in the immediate past version with "I'm sorry, but we try to concentrate our limited resources on supporting the current version, and it is unlikely that it will be fixed. Please post to c.l.p for help." Users are disappointed, but it builds trust, and more so if supported by an official statement.

"Martin v. Löwis" writes:

I'm all in favor of formalizing a policy of when Python releases are produced, and what Python releases, and what kinds of changes they may contain. However, such a policy should be addressed primarily to contributors, as a guidance, not to users, as a promise. So I have problems with both "official" and "support" still.

I see your point, but I don't see how you propose to keep the users from viewing the guidelines to developers as official policy regarding support, albeit hard to interpret. Also, it may just be me, but I don't see an official statement as a "promise". It's a "clarification". '''This is what we're trying to do, so you can make well-informed plans, and not be surprised when you ask for something and we say "but we never thought about doing that, and don't intend to".'''

The way we make policy statements is through the PEP process.

Creating the statement that way is important. But publishing a PEP is not enough. Non-developer users don't read PEPs. After thinking about it a bit, I do agree that "maintain" is more appropriate than "support" (this is after my reply to Terry Reedy, where I wrote that support was OK). Support implies education and adaptation to user needs, but even if that is done by the PSF, it's a separate activity from the development and release processes. While maintenance does include response to user bug reports as part of the development/release process.