Update PEP 11 to be more clear about what is required to gain support for a platform for CPython
This commit is contained in:
Brett Cannon
parent
cbaecb2fab
commit
e95106e8bd
76
pep-0011.txt
76
pep-0011.txt
|
|
@ -2,51 +2,88 @@ PEP: 11
|
|||
Title: Removing support for little used platforms
|
||||
Version: $Revision$
|
||||
Last-Modified: $Date$
|
||||
Author: martin@v.loewis.de (Martin von Löwis)
|
||||
Author: Martin von Löwis <martin@v.loewis.de>,
|
||||
Brett Cannon <brett@python.org>
|
||||
Status: Active
|
||||
Type: Process
|
||||
Content-Type: text/x-rst
|
||||
Created: 07-Jul-2002
|
||||
Post-History: 18-Aug-2007
|
||||
16-May-2014
|
||||
20-Feb-2015
|
||||
|
||||
|
||||
Abstract
|
||||
--------
|
||||
|
||||
This PEP documents operating systems (platforms) which are not
|
||||
supported in Python anymore. For some of these systems,
|
||||
supporting code might be still part of Python, but will be removed
|
||||
in a future release - unless somebody steps forward as a volunteer
|
||||
to maintain this code.
|
||||
This PEP documents how an operating system (platform) becomes
|
||||
supported in CPython and documents past support.
|
||||
|
||||
|
||||
Rationale
|
||||
---------
|
||||
|
||||
Over time, the Python source code has collected various pieces of
|
||||
Over time, the CPython source code has collected various pieces of
|
||||
platform-specific code, which, at some point in time, was
|
||||
considered necessary to use Python on a specific platform.
|
||||
Without access to this platform, it is not possible to determine
|
||||
whether this code is still needed. As a result, this code may
|
||||
either break during the Python evolution, or it may become
|
||||
either break during Python's evolution, or it may become
|
||||
unnecessary as the platforms evolve as well.
|
||||
|
||||
The growing amount of these fragments poses the risk of
|
||||
unmaintainability: without having experts for a large number of
|
||||
platforms, it is not possible to determine whether a certain
|
||||
change to the Python source code will work on all supported
|
||||
change to the CPython source code will work on all supported
|
||||
platforms.
|
||||
|
||||
To reduce this risk, this PEP proposes a procedure to remove code
|
||||
for platforms with no Python users.
|
||||
To reduce this risk, this PEP specifies what is required for a
|
||||
platform to be considered supported by Python as well as providing a
|
||||
procedure to remove code for platforms with few or no Python
|
||||
users.
|
||||
|
||||
Supporting platforms
|
||||
--------------------
|
||||
|
||||
Gaining official platform support requires two things. First, a core
|
||||
developer needs to volunteer to maintain platform-specific code. This
|
||||
core developer can either already be a member of the Python
|
||||
development team or be given contributor rights on the basis of
|
||||
maintaining platform support (it is at the discretion of the Python
|
||||
development team to decide if a person is ready to have such rights
|
||||
even if it is just for supporting a specific platform).
|
||||
|
||||
Second, a stable buildbot must be provided [2]_. This guarantees that
|
||||
platform support will not be accidentally broken by a Python core
|
||||
developer who does not have personal access to the platform. For a
|
||||
buildbot to be considered stable it requires that the machine be
|
||||
reliably up and functioning (but it is up to the Python core
|
||||
developers to decide whether to promote a buildbot to being
|
||||
considered stable).
|
||||
|
||||
This policy does not disqualify supporting other platforms
|
||||
indirectly. Patches which are not platform-specific but still done to
|
||||
add platform support will be considered for inclusion. For example,
|
||||
if platform-independent changes were necessary in the configure
|
||||
script which were motivated to support a specific platform that could
|
||||
be accepted. Patches which add platform-specific code such as the
|
||||
name of a specific platform to the configure script will generally
|
||||
not be accepted without the platform having official support.
|
||||
|
||||
CPU architecture and compiler support are viewed in a similar manner
|
||||
as platforms. For example, to consider the ARM architecture supported
|
||||
a buildbot running on ARM would be required along with support from
|
||||
the Python development team. In general it is not required to have
|
||||
a CPU architecture run under every possible platform in order to be
|
||||
considered supported.
|
||||
|
||||
Unsupporting platforms
|
||||
----------------------
|
||||
|
||||
If a certain platform that currently has special code in it is
|
||||
deemed to be without Python users, a note must be posted in this
|
||||
PEP that this platform is no longer actively supported. This
|
||||
If a certain platform that currently has special code in CPython is
|
||||
deemed to be without enough Python users or lacks proper support from
|
||||
the Python development team and/or a buildbot, a note must be posted
|
||||
in this PEP that this platform is no longer actively supported. This
|
||||
note must include:
|
||||
|
||||
- the name of the system
|
||||
|
|
@ -62,15 +99,15 @@ supported systems). In this case, the name will give the precise
|
|||
condition (usually a preprocessor symbol) that will become
|
||||
unsupported.
|
||||
|
||||
At the same time, the Python source code must be changed to
|
||||
At the same time, the CPython source code must be changed to
|
||||
produce a build-time error if somebody tries to install Python on
|
||||
this platform. On platforms using autoconf, configure must fail.
|
||||
This gives potential users of the platform a chance to step
|
||||
forward and offer maintenance.
|
||||
|
||||
|
||||
Resupporting platforms
|
||||
----------------------
|
||||
Re-supporting platforms
|
||||
-----------------------
|
||||
|
||||
If a user of a platform wants to see this platform supported
|
||||
again, he may volunteer to maintain the platform support. Such an
|
||||
|
|
@ -87,7 +124,7 @@ the product is generally commercially available, and an extended
|
|||
support phase, where paid support is still available, and certain bug
|
||||
fixes are released (in particular security fixes).
|
||||
|
||||
Python's Windows support now follows this lifecycle. A new feature
|
||||
CPython's Windows support now follows this lifecycle. A new feature
|
||||
release X.Y.0 will support all Windows releases whose extended support
|
||||
phase is not yet expired. Subsequent bug fix releases will support
|
||||
the same Windows releases as the original feature release (even if
|
||||
|
|
@ -101,7 +138,7 @@ Visual Studio. That version should have mainstream support when the
|
|||
release is made. Developers of extension modules will generally need
|
||||
to use the same Visual Studio release; they are concerned both with
|
||||
the availability of the versions they need to use, and with keeping
|
||||
the zoo of versions small. The Python source tree will keep
|
||||
the zoo of versions small. The CPython source tree will keep
|
||||
unmaintained build files for older Visual Studio releases, for which
|
||||
patches will be accepted. Such build files will be removed from the
|
||||
source tree 3 years after the extended support for the compiler has
|
||||
|
|
@ -223,6 +260,7 @@ References
|
|||
----------
|
||||
|
||||
.. [1] http://support.microsoft.com/lifecycle/
|
||||
.. [2] http://buildbot.python.org/3.x.stable/
|
||||
|
||||
Copyright
|
||||
---------
|
||||
|
|
|
|||
Loading…
Reference in New Issue