On Sun, Dec 5, 2010 at 14:14, Antoine Pitrou wrote:

On Sun, 05 Dec 2010 22:48:49 +0100 "Martin v. Löwis" wrote:

...

I'd like to tighten PEP 11, and declare a policy that systems older than ten years at the point of a feature release are not supported anymore by default. Older systems where support is still maintained need to be explicitly listed in the PEP, along with the name of the responsible maintainer (I think this would currently only cover OS2/EMX which is maintained by Andrew MacIntyre).

Support for such old platforms can then be removed from the codebase immediately, no need to go through a PEP 11 deprecation cycle.

Seconded!

Thirded! -Brett

...

The other major system affected by this would be Windows 2000, for which we already decided to not support it anymore.

Is there any 2000-specific code (as opposed to XP-compatible)?

Regards

Antoine.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org

On 12/5/2010 4:48 PM, "Martin v. Löwis" wrote:

I'd like to tighten PEP 11, and declare a policy that systems older than ten years at the point of a feature release are not supported anymore by default. Older systems where support is still maintained need to be explicitly listed in the PEP, along with the name of the responsible maintainer (I think this would currently only cover OS2/EMX which is maintained by Andrew MacIntyre).

Support for such old platforms can then be removed from the codebase immediately, no need to go through a PEP 11 deprecation cycle.

As a consequence, I would then like to remove support for Solaris versions older than Solaris 8 (released in January 2000, last updated by Sun in 2004) from the configure script for 3.2b2. A number of other tests in configure.in could probably also be removed, although I personally won't touch them before 3.2.

The other major system affected by this would be Windows 2000, for which we already decided to not support it anymore.

WinXP (released August 2001) should be supported a lot longer than another year ;-) . It is still supported and installed on new systems. -- Terry Jan Reedy

On Mon, Dec 6, 2010 at 7:48 AM, "Martin v. Löwis" wrote:

I'd like to tighten PEP 11, and declare a policy that systems older than ten years at the point of a feature release are not supported anymore by default. Older systems where support is still maintained need to be explicitly listed in the PEP, along with the name of the responsible maintainer (I think this would currently only cover OS2/EMX which is maintained by Andrew MacIntyre).

Support for such old platforms can then be removed from the codebase immediately, no need to go through a PEP 11 deprecation cycle.

As a consequence, I would then like to remove support for Solaris versions older than Solaris 8 (released in January 2000, last updated by Sun in 2004) from the configure script for 3.2b2. A number of other tests in configure.in could probably also be removed, although I personally won't touch them before 3.2.

The other major system affected by this would be Windows 2000, for which we already decided to not support it anymore.

Opinions?

I would prefer to be guided by vendor EOL dates rather than our own arbitrary 10 year limit. The EOL guide I would suggest is "Is the vendor still fixing bugs in that release?". For Solaris 8, the answer to that question is no (Phase 1 EOL support ended in October: http://www.sun.com/service/eosl/eosl_solaris.html) For Windows 2000, the answer is no (Extended Support ended in July: http://support.microsoft.com/lifecycle/?p1=7274) For Windows XP, the answer is yes (Extended Support doesn't end until April 2014: http://windows.microsoft.com/en-us/windows/products/lifecycle#section_2) Since the "Is the vendor still patching it?" guideline gives the "right" answer for the 3 systems mentioned in this thread, it will likely do a better job of covering anomalies like XP than a flat year limit would. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

Nick Coghlan writes:

On Mon, Dec 6, 2010 at 7:48 AM, "Martin v. Löwis" wrote:

...

I'd like to tighten PEP 11 Opinions?

I would prefer to be guided by vendor EOL dates rather than our own arbitrary 10 year limit. The EOL guide I would suggest is "Is the vendor still fixing bugs in that release?".

Since the "Is the vendor still patching it?" guideline gives the "right" answer for the 3 systems mentioned in this thread, it will likely do a better job of covering anomalies like XP than a flat year limit would. +1

I think Nick has a point. If the vendor is willing to patch/support said version, then I think it would be worthwhile for the Python community to provide support EOL dates of prominent Linux distribution : RHEL: https://access.redhat.com/support/policy/updates/errata/ Ubuntu: http://en.wikipedia.org/wiki/List_of_Ubuntu_releases#Version_timeline (http://www.ubuntu.com/products/ubuntu/release-cycle seems to be down) SuSe http://support.novell.com/lifecycle/ I do foresee a possible side-effect regarding Fedora as "maintained for approximately 13 months", because "Release X is supported until one month after the release of Release X+2." http://fedoraproject.org/wiki/LifeCycle Considering the nature of the Fedora project, dropping unsupported fedora distributions may or may not be helpful for Pyhton and it's users. Also, it is not clear what to do about distributions/OSs without any official EOL or life cycles.

On Mon, Dec 6, 2010 at 5:28 PM, "Martin v. Löwis" wrote:

Am 06.12.2010 05:36, schrieb Nick Coghlan:

...

On Mon, Dec 6, 2010 at 7:48 AM, "Martin v. Löwis" wrote:

...

I'd like to tighten PEP 11, and declare a policy that systems older than ten years at the point of a feature release are not supported anymore by default. Older systems where support is still maintained need to be explicitly listed in the PEP, along with the name of the responsible maintainer (I think this would currently only cover OS2/EMX which is maintained by Andrew MacIntyre).

Support for such old platforms can then be removed from the codebase immediately, no need to go through a PEP 11 deprecation cycle.

As a consequence, I would then like to remove support for Solaris versions older than Solaris 8 (released in January 2000, last updated by Sun in 2004) from the configure script for 3.2b2. A number of other tests in configure.in could probably also be removed, although I personally won't touch them before 3.2.

The other major system affected by this would be Windows 2000, for which we already decided to not support it anymore.

Opinions?

I would prefer to be guided by vendor EOL dates rather than our own arbitrary 10 year limit. The EOL guide I would suggest is "Is the vendor still fixing bugs in that release?".

If available, perhaps. Not all system vendors have such a policy, or it may not be easy to find. If that is part of the policy, I'd like to add the specific systems where we use this approach along with the URLs that list the policies in the PEP.

As a counter-example, I think the only way to phase out support for old OpenBSD releases is that we set a date.

I would be fine with an EOL based policy for single-vendor platforms (specifically Solaris and Windows) and a date-based policy for everything else. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

Am 06.12.2010 09:36, schrieb Jeroen Ruigrok van der Werven:

-On [20101206 08:30], "Martin v. Löwis" (martin@v.loewis.de) wrote:

...

As a counter-example, I think the only way to phase out support for old OpenBSD releases is that we set a date.

If you want, I can provide you with specifics on the BSD platforms of what is currently in use, EOL and the future.

If that's publicly documented from a single starting page, having the URL of that page would be appreciated. Also, do users accept that policy? (i.e. would they feel sad if Python releases don't support BSD releases anymore that don't get patches?) For Windows and Solaris, it seems that some users continue to use the system after the vendor stops producing patches, and dislike the prospect of not having Python releases for it anymore. However, they are in clear minority, so by our current policy for minority platforms (no need to support them), that's fine. This really triggered the "ten years" proposal: for quite some time now (20 years) people stop losing interest in operating systems after ten years.

Also, with regard to Windows 2000, XP and its APIs. Didn't XP already switch a bunch of APIs around that 2000 doesn't use? (Need to find that migration document.)

I don't understand the question: what does it meant to switch an API around? XP has added new API that wasn't available in 2000, if that's what you are asking. Regards, Martin

Nick Coghlan writes:

I would be fine with an EOL based policy for single-vendor platforms (specifically Solaris and Windows) and a date-based policy for everything else.

+1 I also think this would be for the best.

On 6 December 2010 09:18, "Martin v. Löwis" wrote:

...

Also, it is not clear what to do about distributions/OSs without any official EOL or life cycles.

Here my proposal stands: 10 years, by default.

How about max(EOL, 10years)? That sounds like it could be a useful guideline. (Personally I'd be sad to see Solaris 8 go in the next few years) Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

On 12/6/2010 4:08 AM, "Martin v. Löwis" wrote:

For Windows and Solaris, it seems that some users continue to use the system after the vendor stops producing patches, and dislike the prospect of not having Python releases for it anymore. However, they are in clear minority, so by our current policy for minority platforms

I quite suspect that XP will be in major use (more than say, current BSD) for some years after MS stops official support. Why rush to drop it? Is there much XP specific stuff in the current xp/vista/7 code? It seems to me that the rule should be something like "around 10 years or end of support, as modified by popularity, the burden of continued support, the availability of test machines, and the availability of people". -- Terry Jan Reedy

Am 06.12.2010 20:25, schrieb Terry Reedy:

On 12/6/2010 4:08 AM, "Martin v. Löwis" wrote:

...

For Windows and Solaris, it seems that some users continue to use the system after the vendor stops producing patches, and dislike the prospect of not having Python releases for it anymore. However, they are in clear minority, so by our current policy for minority platforms

I quite suspect that XP will be in major use (more than say, current BSD) for some years after MS stops official support. Why rush to drop it?

What rush to drop it, specifically? It will be supported as long as Microsoft provides patches, as per Nick's amendment. For Windows XP, the extended lifecycle support (end of security patches) will be on April 8, 2014. I wouldn't call that "rushing", at this point in time. By our current release pace, Python 3.5 might be the first release to not support XP anymore.

Is there much XP specific stuff in the current xp/vista/7 code?

I don't know; I haven't investigated unsupporting XP yet. I'm concerned about Windows 2000, at the moment.

It seems to me that the rule should be something like "around 10 years or end of support, as modified by popularity, the burden of continued support, the availability of test machines, and the availability of people".

In my original posting, I proposed a clause where support could be extended as long as an individual steps forward to provide that support. So if XP remains popular by the time Microsoft stops providing patches for it, some volunteer would have to step forward. Regards, Martin

On 12/6/2010 3:46 PM, "Martin v. Löwis" wrote:

Am 06.12.2010 20:25, schrieb Terry Reedy:

...

I quite suspect that XP will be in major use (more than say, current BSD) for some years after MS stops official support. Why rush to drop it?

What rush to drop it,

On the day MS stops support. But it is a moot support until them. -- Terry Jan Reedy

...

So by this policy, RHEL and SuSE users would be off worse than with my original proposal (10 years).

Red Hat continues to provide patches for RHEL within the "Extended Life Cycle" (years 8, 9 and 10), but it's an optional add-on.

My understanding is that you keep the patches available - but you don't produce any new ones, right?

So another interpretation of the above with Nick's proposal could be 10 years on RHEL. (though obviously I'm biased in favor of RHEL)

I wouldn't count mere availability of old patches on the server as "support".

Approaching this from another angle: please do add me to the "nosy" on any compatibility bugs with running latest python code on RHEL.

I'll try to remember, but really can't promise. But then, as I said before: I think Linux support in Python is particularly easy. For example, there isn't a single distribution-specific test in configure.in.

The other compat issues are in the toolchain: e.g. very recent versions of gcc . In downstream Fedora, we tend to be amongst the first to run into new compilation warnings (and, occasionally, "exciting" code-generation bugs...)

Dropping support for old gcc versions (or other old compiler versions) is probably an issue on its own. It will be difficult to figure out what work-arounds are in place for what particular compiler glitch. Regards, Martin

On Tue, 2010-12-07 at 00:05 +0100, "Martin v. Löwis" wrote:

...

...

So by this policy, RHEL and SuSE users would be off worse than with my original proposal (10 years).

Red Hat continues to provide patches for RHEL within the "Extended Life Cycle" (years 8, 9 and 10), but it's an optional add-on.

My understanding is that you keep the patches available - but you don't produce any new ones, right?

It typically involves backporting (and testing) security fixes to the older versions of the various OS packages. Whether or not the results of that work count as "new patches" is debatable. I don't know if CentOS and the other people who rebuild the RHEL sources track those final 3 years. Dave