|
|
@@ -1,5 +1,5 @@ |
|
|
PEP: 11 |
|
|
Title: Removing support for little used platforms |
|
|
Title: CPython platform support |
|
|
Version: $Revision$ |
|
|
Last-Modified: $Date$ |
|
|
Author: Martin von Löwis <martin@v.loewis.de>, |
|
Expand All
|
@@ -14,109 +14,137 @@ Post-History: 18-Aug-2007, |
|
|
|
|
|
|
|
|
Abstract |
|
|
-------- |
|
|
======== |
|
|
|
|
|
This PEP documents how an operating system (platform) becomes |
|
|
supported in CPython and documents past support. |
|
|
supported in CPython, what platforms are currently supported, and |
|
|
documents past support. |
|
|
|
|
|
|
|
|
Rationale |
|
|
--------- |
|
|
========= |
|
|
|
|
|
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. |
|
|
considered necessary to use CPython 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 Python's evolution, or it may become |
|
|
either break during CPython's evolution, or it may become |
|
|
unnecessary as the platforms evolve as well. |
|
|
|
|
|
The growing amount of these fragments poses the risk of |
|
|
Allowing these fragments to grow 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 CPython source code will work on all supported |
|
|
platforms. |
|
|
|
|
|
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 |
|
|
platform to be considered supported by CPython as well as providing a |
|
|
procedure to remove code for platforms with few or no CPython |
|
|
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 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 |
|
|
- the first release number that does not support this platform |
|
|
anymore, and |
|
|
- the first release where the historical support code is actively |
|
|
removed |
|
|
|
|
|
In some cases, it is not possible to identify the specific list of |
|
|
systems for which some code is used (e.g. when autoconf tests for |
|
|
absence of some feature which is considered present on all |
|
|
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 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. |
|
|
|
|
|
|
|
|
Re-supporting platforms |
|
|
----------------------- |
|
|
|
|
|
If a user of a platform wants to see this platform supported |
|
|
again, they may volunteer to maintain the platform support. Such an |
|
|
offer must be recorded in the PEP, and the user can submit patches |
|
|
to remove the build-time errors, and perform any other maintenance |
|
|
work for the platform. |
|
|
This PEP also lists what plaforms *are* supported by the CPython |
|
|
interpreter. This lets people know what platforms are directly |
|
|
supported by the CPython development team. |
|
|
|
|
|
|
|
|
Support tiers |
|
|
============= |
|
|
|
|
|
Platform support is broken down into *tiers*. Each tier comes with |
|
|
different requirements which lead to different promises being made |
|
|
about support. |
|
|
|
|
|
To be promoted to a tier, steering council support is required and is |
|
|
expected to be driven by team consensus. Demotion to a lower tier |
|
|
occurs when the requirements of the current tier are no longer met for |
|
|
a platform for an extended period of time based on the judgment of |
|
|
the release manager or steering council. For platforms which no longer |
|
|
meet the requirements of any tier by b1 of a new feature release, an |
|
|
announcement will be made to warn the community of the pending removal |
|
|
of support for the platform (e.g. in the b1 announcement). If the |
|
|
platform is not brought into line for at least one of the tiers by the |
|
|
first release candidate, it will be listed as unsupported in this PEP. |
|
|
|
|
|
Tier 1 |
|
|
------ |
|
|
|
|
|
- `CI failures <https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>`__ block releases. |
|
|
- Changes which would break the ``main`` branch are not allowed to be merged; |
|
|
any breakage should be fixed or reverted immediately. |
|
|
- All core developers are responsible to keep ``main``, and thus these |
|
|
platforms, working. |
|
|
- Failures on these platforms **block a release**. |
|
|
|
|
|
======================== ===== |
|
|
Target Triple Notes |
|
|
======================== ===== |
|
|
i686-pc-windows-msvc |
|
|
x86_64-pc-windows-msvc |
|
|
x86_64-apple-darwin BSD libc, clang |
|
|
x86_64-unknown-linux-gnu glibc, gcc |
|
|
======================== ===== |
|
|
|
|
|
|
|
|
Tier 2 |
|
|
------ |
|
|
|
|
|
- Must have a reliable buildbot. |
|
|
- At least **two** core developers are signed up to support the platform. |
|
|
- Changes which break any of these platforms are to be **fixed or |
|
|
reverted within 24 hours**. |
|
|
- Failures on these platforms **block a release**. |
|
|
|
|
|
=========================== ========================== ============================================== ======== |
|
|
Target Triple Notes Buildbot Contacts |
|
|
=========================== ========================== ============================================== ======== |
|
|
aarch64-apple-darwin clang https://buildbot.python.org/all/#/builders/725 Ned Deily, Ronald Oussoren, Dong-he Na |
|
|
aarch64-unknown-linux-gnu glibc, gcc https://buildbot.python.org/all/#/builders/125 Petr Viktorin, Victor Stinner |
|
|
|
|
|
|
|
glibc, clang https://buildbot.python.org/all/#/builders/234 Victor Stinner, Gregory P. Smith |
|
|
powerpcle-unknown-linux-gnu glibc, gcc https://buildbot.python.org/all/#/builders/90 Petr Viktorin, Victor Stinner |
|
|
x86_64-unknownlinux-gnu glibc, clang https://buildbot.python.org/all/#/builders/441 Victor Stinner, Gregory P. Smith |
|
|
=========================== ========================== ============================================== ======== |
|
|
|
|
|
|
|
|
Tier 3 |
|
|
------ |
|
|
|
|
|
- Must have a reliable buildbot. |
|
|
- At least **one** core developer is signed up to support the platform. |
|
|
- No response SLA to failures. |
|
|
- Failures on these platforms do **not** block a release. |
|
|
|
|
|
============================== =========================== ============================================== ======== |
|
|
Target Triple Notes Buildbot Contacts |
|
|
============================== =========================== ============================================== ======== |
|
|
aarch64-pc-windows-msvc https://buildbot.python.org/all/#/builders/729 Steve Dower |
|
|
powerpcle-unknown-linux-gnu glibc, clang https://buildbot.python.org/all/#/builders/435 Victor Stinner |
|
|
x86_64-unknown-freebsd BSD libc, clang https://buildbot.python.org/all/#/builders/172 Victor Stinner |
|
|
armv7l-unknown-linux-gnueabihf Raspberry Pi OS, glibc, gcc https://buildbot.python.org/all/#/builders/424 Gregory P. Smith |
|
|
============================== =========================== ============================================== ======== |
|
|
|
|
|
|
|
|
All other platforms |
|
|
------------------- |
|
|
|
|
|
Support for a platform may be partial within the code base, such as |
|
|
from active development around platform support or accidentally. |
|
|
Code changes to platforms not listed in the above tiers may be rejected |
|
|
or removed from the code base without a deprecation process if they |
|
|
cause a maintenance burden or obstruct general improvements. |
|
|
|
|
|
Platforms not listed here may be supported by the wider Python |
|
|
community in some way. If your desired platform is not listed above, |
|
|
please perform a search online to see if someone is already providing |
|
|
support in some form. |
|
|
|
|
|
|
|
|
Notes |
|
|
----- |
|
|
|
|
|
Microsoft Windows |
|
|
----------------- |
|
|
''''''''''''''''' |
|
|
|
|
|
Microsoft has established a policy called product support lifecycle |
|
|
[1]_. Each product's lifecycle has a mainstream support phase, where |
|
Expand All
|
@@ -130,9 +158,6 @@ phase is not yet expired. Subsequent bug fix releases will support |
|
|
the same Windows releases as the original feature release (even if |
|
|
the extended support phase has ended). |
|
|
|
|
|
Because of this policy, no further Windows releases need to be listed |
|
|
in this PEP. |
|
|
|
|
|
Each feature release is built by a specific version of Microsoft |
|
|
Visual Studio. That version should have mainstream support when the |
|
|
release is made. Developers of extension modules will generally need |
|
Expand All
|
@@ -144,8 +169,9 @@ patches will be accepted. Such build files will be removed from the |
|
|
source tree 3 years after the extended support for the compiler has |
|
|
ended (but continue to remain available in revision control). |
|
|
|
|
|
|
|
|
Legacy C Locale |
|
|
--------------- |
|
|
''''''''''''''' |
|
|
|
|
|
Starting with CPython 3.7.0, \*nix platforms are expected to provide |
|
|
at least one of ``C.UTF-8`` (full locale), ``C.utf8`` (full locale) or |
|
Expand All
|
@@ -156,8 +182,36 @@ Any Unicode-related integration problems that occur only in the legacy ``C`` |
|
|
locale and cannot be reproduced in an appropriately configured non-ASCII |
|
|
locale will be closed as "won't fix". |
|
|
|
|
|
|
|
|
Unsupporting platforms |
|
|
====================== |
|
|
|
|
|
If a platform drops out of tiered support, a note must be posted |
|
|
in this PEP that the platform is no longer actively supported. This |
|
|
note must include: |
|
|
|
|
|
- the name of the system |
|
|
- the first release number that does not support this platform |
|
|
anymore, and |
|
|
- the first release where the historical support code is actively |
|
|
removed |
|
|
|
|
|
In some cases, it is not possible to identify the specific list of |
|
|
systems for which some code is used (e.g. when autoconf tests for |
|
|
absence of some feature which is considered present on all |
|
|
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 CPython source code must be changed to |
|
|
produce a build-time error if somebody tries to install CPython 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. |
|
|
|
|
|
|
|
|
No-longer-supported platforms |
|
|
----------------------------- |
|
|
============================= |
|
|
|
|
|
* | Name: MS-DOS, MS-Windows 3.x |
|
|
| Unsupported in: Python 2.0 |
|
Expand Down
Expand Up
|
@@ -276,15 +330,15 @@ No-longer-supported platforms |
|
|
| Code removed in: Python 3.7 |
|
|
|
|
|
References |
|
|
---------- |
|
|
========== |
|
|
|
|
|
.. [1] http://support.microsoft.com/lifecycle/ |
|
|
.. [2] http://buildbot.python.org/3.x.stable/ |
|
|
|
|
|
Copyright |
|
|
--------- |
|
|
========= |
|
|
|
|
|
This document has been placed in the public domain. |
|
|
This document is placed in the public domain or under the |
|
|
CC0-1.0-Universal license, whichever is more permissive. |
|
|
|
|
|
|
|
|
|
|
Expand Down
|
|