[Python-Dev] PEP 11: Dropping support for ten year old systems

[Nick Coghlan]

On Mon, Dec 6, 2010 at 5:28 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Am 06.12.2010 05:36, schrieb Nick Coghlan:
>> On Mon, Dec 6, 2010 at 7:48 AM, "Martin v. Löwis" <martin at v.loewis.de> 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 at gmail.com   |   Brisbane, Australia