Baseline-Feature-Releases und Feature-Release-Serien

Baseline-Feature-Releases sind im Wesentlichen die bestehenden Feature-Releases, denen ein neuer Name gegeben wird, um sie von den neuen inkrementellen Feature-Releases zu unterscheiden und auch um anzuzeigen, dass sie im Gegensatz zu ihren Vorgängern nicht mehr als Feature-Complete bei der Veröffentlichung gelten.

Baseline-Feature-Releases würden weiterhin eine neue Feature-Release-Serie definieren und die folgenden Sprach-, Build- und Installationskompatibilitätsbeschränkungen für den Rest dieser Serie festlegen:

• Python-Sprachgrammatik
• Format des AST-Moduls ast
• CPython-Interpreter-Opcode-Format
• Magische Nummer und Dateinamens-Kompatibilitäts-Tags für pyc-Dateien
• Kompatibilitäts-Tags für Erweiterungsmodul-Dateinamen
• Kompatibilitäts-Tags für Wheel-Archive
• Standardverzeichnisse für Paket- und Modulimporte
• Standard-Installationsdateiname und -verzeichnisse

Baseline-Feature-Releases wären auch weiterhin die einzigen Releases, bei denen

• neue Deprecations, ausstehende Deprecations und andere Warnungen eingeführt werden können
• bestehende ausstehende Deprecations in vollständige Deprecations umgewandelt werden können
• bestehende Warnungen in Fehler umgewandelt werden können
• andere Änderungen, die "Portierung zu Python X.Y"-Einträge im "What's New"-Dokument erfordern, eingeführt werden können

Schlüsselmerkmale einer Feature-Release-Serie

• eine Installation innerhalb einer Feature-Release-Serie nicht mit Installationen anderer Feature-Release-Serien kollidiert (d. h. sie können parallel installiert werden)
• eine Installation innerhalb einer Feature-Release-Serie kann auf eine spätere Mikro-Version innerhalb derselben Serie aktualisiert werden, ohne dass eine Neuinstallation oder andere Änderungen an zuvor installierten Komponenten erforderlich sind

Schlüsselmerkmale eines Baseline-Feature-Releases

• in einem Baseline-Feature-Release gilt sys.version_info.feature_complete == False
• in einem Baseline-Feature-Release gilt sys.version_info.micro == 0
• Baseline-Feature-Releases können Änderungen mit höherem Risiko an der Sprache und dem Interpreter enthalten, wie z. B. Grammatikmodifikationen, große Refactorings interner Interpreter- und Standardbibliotheken oder potenziell invasive Feature-Ergänzungen, die das Risiko unbeabsichtigter Nebenwirkungen auf andere bestehende Funktionalitäten bergen.
• Features, die in einem Baseline-Feature-Release eingeführt werden, sind die *einzigen* Features, die sys.version_info als alleinigen Laufzeitindikator für die Verfügbarkeit des Features nutzen dürfen.

Wichtige Erwartungen an Feature-Release-Serien und Baseline-Feature-Releases

• die meisten öffentlichen Projekte testen nur gegen die *aktuellste* Mikro-Version innerhalb einer Release-Serie.
• viele (die meisten?) öffentlichen Projekte fügen eine neue Release-Serie erst zur Testmatrix hinzu, *nachdem* das anfängliche Baseline-Feature-Release bereits veröffentlicht wurde, was es schwierig machen kann, Probleme zu beheben, die die Bereitstellung neuer Flags oder APIs zur expliziten Opt-in-Verhaltensweise erfordern, nachdem sich das Standardverhalten geändert hat.
• private Projekte mit bekannten Zielumgebungen testen gegen die Mikro-Version, die sie tatsächlich verwenden.
• die meisten privaten Projekte erwägen ebenfalls erst die Migration zu einer neuen Release-Serie, *nachdem* das anfängliche Baseline-Feature-Release bereits veröffentlicht wurde, was erneut ein Problem darstellt, wenn die Lösung ihrer Probleme eine API-Ergänzung erfordert.

Die Hauptmotivation des Vorschlags in diesem PEP ist, dass das oben beschriebene Verhalten öffentlicher und privater Projekte keine *neuen* Erwartungen sind: Es handelt sich um Beschreibungen der Art und Weise, wie CPython-Release-Serien von der breiteren Community bereits heute gehandhabt werden. Daher stellt der PEP einen Versuch dar, unsere Release-Richtlinien und -Prozesse anzupassen, um besser zu den Arbeitsweisen der breiteren Community zu passen, anstatt unsere Prozesse so zu ändern, dass die breitere Community sich an uns anpassen muss und nicht umgekehrt.

Inkrementelle Feature-Releases

Inkrementelle Feature-Releases sind die wichtigste neue Prozess-Ergänzung, die von diesem PEP vorgeschlagen wird. Sie unterliegen denselben strengen Laufzeitkompatibilitätsanforderungen wie die bestehenden Wartungs-Releases, hätten aber die folgenden gelockerteren Richtlinien für API-Ergänzungen und -Verbesserungen:

• neue öffentliche APIs können zu jedem Standardbibliotheksmodul (einschließlich Built-ins) hinzugefügt werden.
• vorbehaltlich der unten genannten Anforderung zur Feature-Erkennung können vorhandenen APIs (einschließlich Built-ins) neue optionale Argumente hinzugefügt werden.
• neue öffentliche APIs können zur stabilen C-ABI hinzugefügt werden (mit entsprechenden Versionsschutz).
• neue öffentliche APIs können zur CPython-C-API hinzugefügt werden.
• mit Genehmigung des Release Managers können rückwärtskompatible Zuverlässigkeitsverbesserungen an bestehenden APIs und syntaktischen Konstrukten vorgenommen werden.
• mit Genehmigung des Release Managers können Leistungsverbesserungen für bestehende APIs und syntaktische Konstrukte integriert werden.

Die Absicht dieser Politikänderung ist es, Nutzungsverbesserungen für neue (und bestehende!) Sprachfeatures zeitnaher zu liefern, anstatt von Benutzern die inhärente Verzögerung und Kosten des Wartens auf die nächste Feature-Release-Serie und deren anschließendes Upgrade zu verlangen.

Es ist auch so konzipiert, dass die Genehmigung, ein Feature zur nächsten Baseline-Feature-Release hinzuzufügen, getrennt von der Frage betrachtet werden kann, ob es in die nächste inkrementelle Feature-Release für die aktuelle Release-Serie aufgenommen werden soll, was potenziell ermöglicht, dass die erste Aufgabe von Freiwilligen erledigt wird, während letztere Aktivität von bezahlten Mitarbeitern gehandhabt werden könnte (z. B. Kunden von kommerziellen Python-Distributoren könnten beantragen, dass ihr Anbieter ein Feature zurückportiert, oder Kernentwickler könnten anbieten, bestimmte Backports auf Vertragsbasis durchzuführen). (Es gäbe potenzielle ethische Bedenken, Bugfixes auf diese Weise zu sperren, aber diese Bedenken gelten nicht für Backports neuer Features.)

Schlüsselmerkmale eines inkrementellen Feature-Releases

• in einem inkrementellen Feature-Release gilt sys.version_info.feature_complete == False
• in einem inkrementellen Feature-Release gilt sys.version_info.micro != 0
• alle in einem inkrementellen Feature-Release hinzugefügten API-Ergänzungen müssen eine effiziente Laufzeit-Feature-Erkennung unterstützen, die nicht auf sys.version_info oder Introspektion von Laufzeit-Code-Objekten beruht. In den meisten Fällen reicht eine einfache hasattr-Prüfung des betroffenen Moduls aus, aber wenn nicht, muss ein alternativer Ansatz als Teil der Feature-Ergänzung implementiert werden. Vorhandene Beispiele in diesem Bereich sind das Attribut pickle.HIGHEST_PROTOCOL, die Menge hashlib.algorithms_available und die verschiedenen os.supports_*-Sets, die das os-Modul bereits für plattformabhängige Fähigkeitserkennung bietet.
• um die Pickle-Kompatibilität in Umgebungen mit gemischten Versionen aufrechtzuerhalten und eine einfachere Kompatibilitätstests über mehrere API-Versionen innerhalb derselben Release-Serie zu ermöglichen, müssen alle in einem inkrementellen Feature-Release hinzugefügten API-Ergänzungen die neue sys.feature_limit-Einstellung unterstützen, wie im nächsten Abschnitt beschrieben.

Wichtige Erwartungen an inkrementelle Feature-Releases

• "bestehende Installationen bei einem Upgrade nicht brechen" bleibt eine wichtige Anforderung für alle Mikro-Releases, auch bei der flexibleren Politik zur Einbeziehung von Änderungen.
• einschneidendere Änderungen sollten weiterhin auf das nächste Baseline-Feature-Release verschoben werden.
• öffentliche Python-Projekte, die beginnen, Features zu nutzen, die in einem inkrementellen Feature-Release hinzugefügt wurden, sollten ihre Python-Requires-Metadaten entsprechend setzen (Projekte tun dies bereits, wenn nötig – z. B. erfordert aiohttp spezifisch 3.5.3 oder neuer aufgrund eines Problems mit asyncio.get_event_loop() in früheren Versionen).

Einige Standardbibliotheksmodule können auch ihre eigenen Beschränkungen für akzeptable Änderungen in inkrementellen Feature-Releases auferlegen (zum Beispiel sollte nur ein Baseline-Feature-Release jemals neue Hash-Algorithmen zu hashlib.algorithms_guaranteed hinzufügen – inkrementelle Feature-Releases dürften nur Algorithmen zu hashlib.algorithms_available hinzufügen).

Aufrechterhaltung der Interoperabilität über inkrementelle Feature-Releases hinweg

Es ist eine gängige Praxis, das Python-Modul pickle zu verwenden, um Informationen zwischen Python-Prozessen auszutauschen, die mit verschiedenen Python-Versionen laufen. Zwischen Release-Serien wird erwartet, dass diese Kompatibilität nur in eine Richtung läuft (d. h. mit Ausnahme von veralteten APIs können Python "X.Y+1"-Prozesse Pickle-Archive lesen, die von Python "X.Y"-Prozessen erstellt wurden, aber umgekehrt gilt dies nicht, da die neueren Archive Attribute und Parameter referenzieren können, die in der älteren Version nicht existieren).

Innerhalb einer Release-Serie wird jedoch erwartet, dass dies in beide Richtungen gilt, da die "Keine neuen Features"-Politik bedeutet, dass fast alle Pickle-Archive, die unter Python "X.Y.Z+1" erstellt wurden, von Python "X.Y.Z"-Prozessen gelesen werden können.

Ebenso werden Python-Bibliotheken und -Anwendungen oft nur gegen die neueste Version einer Release-Serie getestet, und dies reicht normalerweise aus, um den Code auch auf früheren Versionen derselben Serie funktionsfähig zu halten.

Das Zulassen von Feature-Ergänzungen in späteren "X.Y.Z"-Releases ohne Möglichkeit, sie abzuschalten, würde ein Problem für diese gängigen Praktiken darstellen, da eine Bibliothek oder Anwendung, die bei Tests mit CPython-Version "X.Y.Z" gut funktioniert, auf früheren Versionen fehlschlagen würde, wenn sie ein Feature verwendet, das neu in "X.Y.Z" eingeführt wurde, und alle von ihr erstellten Pickle-Archive, die auf diesen neuen Schnittstellen basieren, wären möglicherweise auch nicht auf den älteren Versionen lesbar.

Um diese Probleme zu lösen, würde ein neues Attribut sys.feature_limit hinzugefügt werden, als strukturierte Sequenz, die den ersten 3 Feldern in sys.version_info entspricht (major, minor, micro).

Eine neue CLI-Option (--feature-limit X.Y.Z) und Umgebungsvariable (PYTHONFEATURELIMIT=X.Y.Z) würden verwendet, um dieses Attribut zu setzen. Die PyCoreConfig-Struktur würde ebenfalls ein neues Feld erhalten.

wchar_t *feature_limit;

Wenn das Limit nicht explizit gesetzt ist, würde es standardmäßig auf die ersten 3 Felder in sys.version_info gesetzt. Wenn das Limit auf einen Wert gesetzt wird, der außerhalb der unteren Grenze von sys.version_info[:2] und der oberen Grenze von sys.version_info[:3] liegt, wird es auf diese Grenzen begrenzt, wobei bei Bedarf mit Nullen aufgefüllt wird.

Zum Beispiel würden bei einer aktuellen Version von "3.9.3" die nominellen Limits wie folgt in Laufzeit-sys.feature_limit-Werte konvertiert:

3 => (3, 9, 0)
3.8.1 => (3, 9, 0)
3.9 => (3, 9, 0)
3.9.2 => (3, 9, 2)
<unset> => (3, 9, 3)
3.9.3 => (3, 9, 3)
3.9.4 => (3, 9, 3)
4 => (3, 9, 3)

Neue APIs, die in ein inkrementelles Feature-Release zurückportiert werden, müssten einen Guard enthalten, der die API aus dem Modul löscht, wenn das Feature-Limit zu niedrig ist.

def feature_api():
    ...

_version_feature_api_added = (3, 9, 1)
if _version_feature_api_added > sys.feature_limit:
    del feature_api

Ebenso müssten neue Parameter einen Guard enthalten, der die Funktionssignatur an die alte anpasst.

def feature_api(old_param1, old_param2, new_param=default):
    """Updated API docstring"""
    ...

_version_feature_api_changed = (3, 9, 1)
if _version_feature_api_changed > sys.feature_limit:
    _new_feature_api = feature_api
    def feature_api(old_param1, old_param2):
        """Legacy API docstring"""
        return _new_feature_api(old_param1, old_param2)

Die Strukturierung der Guards auf diese Weise würde die Code-Struktur zwischen dem Hauptentwicklungszweig und den Backport-Zweigen so ähnlich wie möglich halten, damit zukünftige Bugfixes weiterhin automatisch zurückportiert werden können.

Es wird erwartet, dass irgendwann Hilfsfunktionen und/oder zusätzliche automatisierte Tests hinzugefügt werden, um sicherzustellen, dass diese zurückportierten APIs angemessen geschützt sind. Es scheint jedoch sinnvoll zu sein, auf spezifische konkrete Beispiele zu warten, um das Design dieser APIs und automatisierten Tests voranzutreiben, anstatt sie nur auf der Grundlage hypothetischer Beispiele zu entwerfen.

Feature-Complete-Release und nachfolgende Wartungs-Releases

Das Feature-Complete-Release für eine gegebene Feature-Release-Serie würde unter der normalen Politik für ein inkrementelles Feature-Release entwickelt werden, hätte aber ein unterscheidendes Merkmal:

• in einem Feature-Complete-Release gilt sys.version_info.feature_complete == True

Alle nachfolgenden Wartungs- und reinen Sicherheitsfix-Releases würden ebenfalls dieses Flag gesetzt haben und könnten informell als "Feature-Complete-Releases" bezeichnet werden. Für die Definition der Release-Serie ist das Feature-Complete-Release jedoch das erste, das dieses Flag auf "True" setzt.

Vorgeschlagene Politikänderung für vorläufige APIs

Um die Konsistenz bei der Verwaltung von vorläufigen APIs zu verbessern, schlägt dieser PEP vor, dass vorläufige APIs nach dem Feature-Complete-Release für eine gegebene Release-Serie regulären Rückwärtskompatibilitätsanforderungen unterliegen.

Andere Aspekte der Verwaltung vorläufiger APIs würden bleiben, wie sie heute sind. Solange eine API im vorläufigen Zustand verbleibt, gelten für diese API in Baseline- und inkrementellen Feature-Releases keine regulären Rückwärtskompatibilitätsanforderungen.

Diese Politik wird voraussichtlich zu mehr Klarheit für Endbenutzer führen (da selbst vorläufige APIs in der Feature-Complete-Release für diese Release-Serie stabil werden), mit minimalen praktischen Nachteilen für Maintainer der Standardbibliothek, basierend auf der folgenden Analyse dokumentierter API-Ergänzungen und -Änderungen in Mikro-Releases von CPython seit 3.0.0:

• 21 3.x.1 Version hinzugefügt/geänderte Notizen
• 30 3.x.2 Version hinzugefügt/geänderte Notizen
• 18 3.x.3 Version hinzugefügt/geänderte Notizen
• 11 3.x.4 Version hinzugefügt/geänderte Notizen
• 1 3.x.5 Version hinzugefügt/geänderte Notizen
• 0 3.x.6+ Version hinzugefügt/geänderte Notizen

Wenn nach der Baseline-Release Änderungen vorgenommen werden müssen, geschieht der Großteil davon innerhalb der ersten beiden Wartungs-Releases, die immer innerhalb von 12 Monaten nach der Baseline-Release erfolgen.

(Hinweis: Diese Zählungen sind nicht nur für vorläufige APIs – sie umfassen alle APIs, bei denen semantische Änderungen nach der Baseline-Release vorgenommen wurden, die in der Dokumentation berücksichtigt werden mussten. Um Änderungen nicht doppelt zu zählen, schließen die Zahlen alle Änderungsmarkierungen aus dem Abschnitt "What's New" aus.)

Warum dieser Vorschlag anstelle von häufigeren Baseline-Feature-Releases?

Die Änderungen am Dateisystemlayout und andere inhärent inkompatible Änderungen, die mit einem Baseline-Feature-Release verbunden sind, verursachen zusätzliche Arbeit für große Teile der breiteren Python-Community.

Die Entkopplung dieser Release-Änderungen von der Versionsnummerierung von Python ist etwas, das an sich bereits rückwärts inkompatible Änderungen mit sich bringen würde, sowie die Anpassung der Erwartungen der Community dahingehend, welche Versionen übereinander installiert werden können und welche parallel auf einem einzelnen System installiert werden können.

Wir haben auch keine einfache Möglichkeit, der Community Unterschiede in den Support-Zeiträumen zu kommunizieren, wie z. B. "Unterstütze Python-Version X.Y nur bis X.Y+1 verfügbar ist, aber unterstütze X.Z bis X.Z+2 verfügbar ist".

Daher geht dieser PEP als Ausgangspunkt davon aus, dass die überwiegende Mehrheit der Python-Benutzer sich einfach *nicht darum kümmern muss*, dass wir unsere Release-Politik ändern, und die einzigen, die betroffen sein sollten, sind diejenigen, die gespannt auf Verbesserungen der Standardbibliothek (und andere abwärtskompatible Interpreter-Erweiterungen) warten, sowie diejenigen, die geschäftskritische Anwendungen in komplexen Deployment-Umgebungen verwalten müssen.

Auswirkungen auf die Entwicklung von Python-Bibliotheken

Viele Python-Bibliotheken (sowohl Open Source als auch proprietär) folgen derzeit der Praxis, ausschließlich gegen die neueste Micro-Version innerhalb jeder Feature-Release-Serie zu testen, die das Projekt noch unterstützt.

Die Designannahme in diesem PEP ist, dass diese Praxis während der Feature-Release-Phase einer Release-Serie fortgesetzt wird, mit der Erwartung, dass jeder, der sich entscheidet, eine neue Release-Serie zu übernehmen, bevor sie Feature-komplett ist, die inkrementellen Feature-Releases eng verfolgen wird.

Bibliotheken, die eine frühere Feature-Release-Serie unterstützen, werden unwahrscheinlich Features übernehmen, die in einem inkrementellen Feature-Release hinzugefügt wurden, und wenn sie ein solches Feature übernehmen, dann sollten alle damit verbundenen Fallback-Kompatibilitätsstrategien so implementiert werden, dass sie auch auf früheren Releases dieser Serie wirksam sind.

Auswirkungen auf die geplante Unterstützungsperiode für das wissenschaftliche Python-Ökosystem

Basierend auf Diskussionen bei SciPy 2019 wird derzeit eine NEP ausgearbeitet [2], um eine gemeinsame Konvention im Scientific Python-Ökosystem für das Abkündigen der Unterstützung älterer Python-Versionen zu definieren.

Obwohl die genaue Formulierung dieser Politik noch diskutiert wird, war der erste Vorschlag sehr einfach: Unterstützung für jede Python-Feature-Version, die in den letzten 42 Monaten veröffentlicht wurde.

Bei einer Feature-Release-Kadenz von 18 Monaten bedeutet dies, immer mindestens die beiden neuesten Feature-Releases zu unterstützen und dann die Unterstützung für alle X.Y.z-Releases etwa 6 Monate nach der Veröffentlichung von X.(Y+2).0 einzustellen. Dies bedeutet, dass es etwa alle zwei Jahre einen 6-monatigen Zeitraum gibt, in dem die drei neuesten Feature-Releases unterstützt werden.

Bei einer Release-Kadenz von 12 Monaten würde dies bedeuten, immer mindestens die drei neuesten Feature-Releases zu unterstützen und dann die Unterstützung für alle X.Y.z-Releases etwa 6 Monate nach der Veröffentlichung von X.(Y+3).0 einzustellen. Dies bedeutet, dass für die Hälfte jedes Jahres die vier neuesten Feature-Releases unterstützt würden.

Bei einer Release-Kadenz von 24 Monaten würde ein 42-monatiger Support-Zyklus bedeuten, immer mindestens die neueste Feature-Version zu unterstützen und dann die Unterstützung für alle X.Y.z-Feature-Releases etwa 18 Monate nach der Veröffentlichung von X.(Y+1).0 einzustellen. Dies bedeutet, dass es alle zwei Jahre einen 6-monatigen Zeitraum gibt, in dem nur eine Feature-Version unterstützt wird (und dieser Zeitraum mit der Vorab-Testphase für die X.(Y+2).0 Baseline-Feature-Version zusammenfällt).

Wichtig für den Vorschlag in diesem PEP: Dieser Support-Zeitraum würde der Empfehlung folgen, dass Bibliotheksentwickler die Unterstützung für die vorherige Release-Serie aufrechterhalten, bis die neueste Release-Serie den Feature-kompletten Status erreicht hat: Das Abkündigen der Unterstützung 18 Monate nach der Baseline-Feature-Version wäre ungefähr gleichbedeutend mit dem Abkündigen der Unterstützung 6 Monate nach der Feature-kompletten Version, ohne genau verfolgen zu müssen, *welche* Version die Serie als Feature-komplett markiert hat.

Auswirkungen auf einfache Deployment-Umgebungen

Für die Zwecke dieses PEP ist eine "einfache" Deployment-Umgebung jeder Anwendungsfall, bei dem es einfach ist sicherzustellen, dass alle Zielumgebungen gleichzeitig auf eine neue Python-Micro-Version aktualisiert werden (oder zumindest vor der Einführung neuer übergeordneter Anwendungsversionen), und es gibt keine Anforderung, dass ältere Python-Versionen Pickle-Streams, die mit der neueren Python-Version generiert wurden, zuverlässig lesen können, so dass alle durchgeführten Vorab-Tests nur eine einzige Python-Micro-Version als Ziel haben müssen.

Der einfachste solche Fall wäre das Skripting für den persönlichen Gebrauch, bei dem die Test- und Zielumgebungen exakt dieselbe Umgebung sind.

Ähnlich einfache Umgebungen wären containerisierte Webdienste, bei denen derselbe Python-Container in der CI-Pipeline wie im Deployment verwendet wird, und jede Anwendung, die ihre eigene Python-Laufzeitumgebung bündelt, anstatt sich auf ein bereits vorhandenes Python-Deployment auf dem Zielsystem zu verlassen.

Für diese Anwendungsfälle sollte dieser PEP keine signifikanten Auswirkungen haben - nur eine einzige Micro-Version muss getestet werden, unabhängig davon, ob diese Version Feature-komplett ist oder nicht.

Auswirkungen auf komplexe Deployment-Umgebungen

Für die Zwecke dieses PEP sind "komplexe" Deployment-Umgebungen Anwendungsfälle, die nicht das "einfache Deployment"-Kriterium erfüllen: Neue Anwendungsversionen werden im Rahmen des Deployment-Prozesses mit zwei oder mehr unterschiedlichen Micro-Versionen innerhalb derselben Release-Serie kombiniert, anstatt immer genau eine Micro-Version gleichzeitig als Ziel zu haben.

Wenn der Vorschlag in diesem PEP den gewünschten Effekt hat, die Feature-Lieferlatenz zu reduzieren, dann ist davon auszugehen, dass Entwickler, die eine noch nicht Feature-komplette Release-Serie verwenden, die neuen Features auch tatsächlich nutzen werden, sobald sie verfügbar sind. Dies bedeutet dann, dass das Testen gegen eine neuere inkrementelle Feature-Version ein noch weniger gültiger Test auf Kompatibilität mit der Baseline-Feature-Version und älteren inkrementellen Feature-Versionen ist, als das Testen gegen eine neuere Wartungsversion für ältere Wartungsversionen ist.

Eine Option für den Umgang mit solchen Fällen ist, die Verwendung neuer Python-Versionen einfach zu verbieten, bis die Serie den Status "Feature-komplett" erreicht hat. Eine solche Politik wird von vielen Organisationen bereits für neue Feature-Release-Serien angewendet, wobei die Akzeptanz in operativen Umgebungen Monate oder Jahre nach der ursprünglichen Veröffentlichung erfolgt. Wenn diese Politik übernommen wird, könnten solche Organisationen potenziell immer noch alle zwei Jahre eine neue Python-Version übernehmen - diese würde sich dann jedoch auf die Verfügbarkeit der Feature-kompletten Versionen stützen, anstatt auf die Baseline-Feature-Versionen.

Eine weniger strenge Alternative zum vollständigen Verbot wäre die Nutzung der vorgeschlagenen Einstellung PYTHONFEATURELIMIT, um phasenweise Migrationen zu neuen inkrementellen Feature-Releases zu ermöglichen

• zunächst Python X.Y.0 mit PYTHONFEATURELIMIT=X.Y.0 in CI und im Deployment ausrollen
• Python X.Y.1 an CI ausrollen, wobei die Einstellung PYTHONFEATURELIMIT=X.Y.0 beibehalten wird
• Python X.Y.1 basierend auf erfolgreichen CI-Ergebnissen in die Produktion deployen
• Deployment-Umgebungen aktualisieren, um PYTHONFEATURELIMIT=X.Y.1 zu setzen
• erst nachdem alle Deployment-Umgebungen aktualisiert wurden, PYTHONFEATURELIMIT=X.Y.1 in CI setzen
• diesen Prozess für jede neue Version bis einschließlich der Feature-kompletten Version der Release-Serie wiederholen
• sobald die Serie Feature-komplett ist, entweder diesen Prozess zur Konsistenz beibehalten oder die Aktualisierung von PYTHONFEATURELIMIT stoppen und auf der Feature-kompletten Versionsnummer belassen

Dauer der Periode für Feature-Ergänzungen

Dieser PEP schlägt vor, die Feature-Ergänzungen auf 12 Monate nach der ursprünglichen Baseline-Feature-Version zu beschränken.

Die Hauptmotivation dafür ist die Synchronisierung mit dem Ubuntu LTS-Timing, sodass die Feature-komplette Version der Python 3.9.x-Serie im Oktober 2021 veröffentlicht wird, bereit für die Aufnahme in die Ubuntu 22.04-Version. (Andere LTS-Linux-Distributionen wie RHEL, SLES und Debian haben keine feste Veröffentlichungs-Kadenz, sodass sie ihr LTS-Timing leichter an stabile Versionen ihrer Eingaben anpassen können. Canonical hat sich bei ihrem eigenen Release-Zyklus bewusst nicht diese Flexibilität gegeben).

Die 12-monatige Feature-Ergänzungsperiode ergibt sich aus der gleichmäßigen Aufteilung der Zeit von der 2019-10-Veröffentlichung von Python 3.8.0 und einer finalen Python 3.9.x inkrementellen Feature-Version im Jahr 2021-10, zwischen Vorab-Entwicklung und nachfolgenden inkrementellen Feature-Releases.

Dies ist ein Bereich, in dem dieser PEP einen Teil des Vorschlags aus PEP 596 übernehmen könnte, indem diese Aufteilung stattdessen auf etwa 9 Monate Vorab-Entwicklung und etwa 15 Monate inkrementelle Feature-Releases verschoben wird.

• 2019-11: 3.9.0a1
• … zusätzliche Alpha-Releases nach Ermessen des Release Managers
• 2020-03: 3.9.0b1
• 2020-04: 3.9.0b2
• 2020-05: 3.9.0b3 (finale Beta-Version, die ABI-Kompatibilität sperrt)
• 2020-06: 3.9.0rc1
• … zusätzliche Release Candidates nach Ermessen des Release Managers
• 2020-07: 3.9.0 (BFR)
• 2020-10: 3.9.1 (IFR)
• 2021-01: 3.9.2 (IFR)
• 2021-04: 3.9.3 (IFR)
• 2021-07: 3.9.4 (IFR)
• 2021-10: 3.9.5
• 2022-01: 3.9.6
• 2022-04: 3.9.7
• 2022-07: 3.9.8
• 2022-10: 3.9.9 (finale reguläre Wartungsversion)
• … zusätzliche reine Sicherheitsfix-Releases nach Bedarf
• 2025-10: 3.9.x Branch geschlossen

Dieser Ansatz würde bedeuten, dass es immer noch zwei oder drei aktive Branches gäbe, nur dass proportional mehr Zeit mit einem Branch in der "Feature Releases"-Phase verbracht würde, im Vergleich zu den "pre-alpha", "pre-beta" und "pre-release" Phasen.

• 2019-04 -> 2019-10: 3.9.0 Pre-Alpha, 3.8.0 Vorabversion, 3.7.x Wartung
• 2019-10 -> 2020-03: 3.9.0 pre-beta, 3.8.x Wartung
• 2020-03 -> 2020-07: 3.10.0 pre-alpha, 3.9.0 pre-release, 3.8.x Wartung
• 2020-07 -> 2021-10: 3.10.0 pre-alpha, 3.9.x Feature Releases, 3.8.x Wartung
• 2021-10 -> 2022-03: 3.10.0 pre-beta, 3.9.x Wartung
• 2022-03 -> 2022-07: 3.11.0 pre-alpha, 3.10.0 pre-release, 3.9.x Wartung
• 2022-07 -> 2023-10: 3.11.0 pre-alpha, 3.10.x Feature Releases, 3.9.x Wartung
• 2023-10 -> 2024-03: 3.11.0 pre-beta, 3.10.x Wartung
• 2024-03 -> 2024-07: 3.12.0 pre-alpha, 3.11.0 pre-release, 3.10.x Wartung
• ... usw.

Dauer der unveröffentlichten Vor-Alpha-Periode

Im Basisvorschlag dieses PEP beinhalten die vorgeschlagenen Zeitpläne immer noch Perioden, in denen wir 18 Monate lang keine Veröffentlichung aus dem Haupt-Git-Branch machen (z. B. würde 3.9.0b1 im Mai 2020 ausgezweigt und 3.10.0a1 würde erst im November 2021 veröffentlicht). Sie erlauben lediglich, dass eine größere Vielfalt von Änderungen während 12 dieser Monate in den aktuellsten Wartungsbranch zurückportiert wird.

Die Variante des Vorschlags, die den Beta-Branch-Point früher im Lebenszyklus der Release-Serie verschiebt, würde diesen Zeitraum ohne direkte Veröffentlichungen auf 21 Monate verlängern - die einzige Periode, in der Veröffentlichungen direkt aus dem Hauptbranch gemacht würden, wäre das relativ kurze Zeitfenster zwischen dem letzten inkrementellen Feature-Release der vorherigen Release-Serie und dem Beta-Branch-Point einige Monate später.

Obwohl die abwechselnde jährliche Kadenz zwischen "großen grundlegenden Verbesserungen" und "zielgerichteten, risikoarmen API-Verbesserungen" ein bewusstes Merkmal dieses Vorschlags ist, erscheint es dennoch seltsam, so lange auf Feedback zu warten, falls kurz nach dem Branching der vorherigen Release-Serie Änderungen vorgenommen werden.

Eine alternative Möglichkeit, dies zu handhaben, wäre, Alpha-Releases für die nächste Baseline-Feature-Version bereits während der Feature-Ergänzungsphase zu veröffentlichen (ähnlich wie PEP 596 vorschlägt, Python 3.9.0 Alpha-Releases während der Python 3.8.0 Release Candidate-Phase zu veröffentlichen).

Anstatt jedoch spezifische Zeitpläne auf Policy-Ebene festzulegen, könnte es sinnvoll sein, diese Entscheidung den einzelnen Release-Managern zu überlassen, basierend auf den spezifischen Änderungen, die für die von ihnen verwaltete Version vorgeschlagen werden.

Warum nicht direkt auf vollständiges semantisches Versioning umsteigen?

Wenn dies ein Versionsdesign-Dokument für eine neue Sprache wäre, würde es die semantische Versionierung verwenden: Die oben beschriebenen Policies für Baseline-Feature-Releases würden auf X.0.0-Releases angewendet, die Policies für inkrementelle Feature-Releases auf X.Y.0-Releases und die Policies für Wartungs-Releases auf X.Y.Z-Releases.

Das Problem für Python speziell ist, dass alle Policies und Eigenschaften für die parallele Installationsunterstützung und ABI-Kompatibilitätsdefinitionen derzeit mit den ersten *zwei* Feldern der Versionsnummer verbunden sind, und das schon seit fast dreißig Jahren.

Daher ist es sinnvoll, die Frage der Einführung von inkrementellen Feature-Releases von der technischen Frage zu trennen, wie das Versionsnummerierungsschema besser zu den Semantiken der verschiedenen Release-Typen passt.

Wenn der Vorschlag in diesem PEP vom Steering Council für Python 3.9 akzeptiert würde, dann wäre ein besserer Zeitpunkt, diese technische Frage anzugehen, die nachfolgende Baseline-Feature-Version vom Oktober 2022, da es bereits inhärente Kompatibilitätsrisiken bei der Wahl von entweder "Python 4.0" (fehlerhafte Prüfungen, ob die Hauptversion exakt 3 und nicht 3 oder größer ist) oder "Python 3.10" (Code, der fälschlicherweise davon ausgeht, dass die Nebenversion immer genau eine Dezimalstelle enthält) gibt [1].

Während der Text dieses PEP davon ausgeht, dass die im Jahr 2022 veröffentlichte Version 3.10 sein wird (da der PEP-Autor dies persönlich für die vernünftigere und wahrscheinlichste Wahl hält), gibt es komplexe Vor- und Nachteile auf beiden Seiten dieser Entscheidung, und dieser PEP fügt wohl ein potenzielles Pro für die Wahl der "Python 4.0"-Option hinzu (mit der Einschränkung, dass wir auch die betroffenen Installationslayouts und Kompatibilitätsmarkierungen ändern müssten, um nur die Hauptversionsnummer und nicht sowohl die Haupt- als auch die Nebenversionsnummer zu berücksichtigen).

Wenn eine solche Änderung der Versionsnummer vorgeschlagen und akzeptiert würde, dann würde die oben gezeigte Beispiel-Timeline für 3.10.x stattdessen zur folgenden Timeline für die 4.x-Serie werden.

• 2021-11: 4.0.0a1
• … zusätzliche Alpha-Releases nach Ermessen des Release Managers
• 2022-05: 4.0.0b1
• … zusätzliche Beta-Releases nach Ermessen des Release Managers
• 2022-08: 4.0.0bX (finale Beta-Version, die ABI-Kompatibilität sperrt)
• 2022-09: 4.0.0rc1
• … zusätzliche Release Candidates nach Ermessen des Release Managers
• 2022-10: 4.0.0 (BFR)
• 2023-01: 4.1.0 (IFR)
• 2023-04: 4.2.0 (IFR)
• 2023-07: 4.3.0 (IFR)
• 2023-10: 4.4.0 (IFR)
• 2024-01: 4.4.1
• 2024-04: 4.4.2
• 2024-07: 4.4.3
• 2024-10: 4.4.4 (finale reguläre Wartungsversion)
• … zusätzliche reine Sicherheitsfix-Releases nach Bedarf
• 2027-10: 4.x-Branch geschlossen

Und die Prognose für den Fünfjahresplan sähe wie folgt aus:

• 2019-04 -> 2019-10: 3.9.0 Pre-Alpha, 3.8.0 Vorabversion, 3.7.x Wartung
• 2019-10 -> 2020-05: 3.9.0 Vor-Beta, 3.8.x Wartung
• 2020-05 -> 2020-10: 4.0.0 pre-alpha, 3.9.0 pre-release, 3.8.x Wartung
• 2020-10 -> 2021-10: 4.0.0 pre-alpha, 3.9.x Feature Releases, 3.8.x Wartung
• 2021-10 -> 2022-05: 4.0.0 pre-beta, 3.9.x Wartung
• 2022-05 -> 2022-10: 5.0.0 pre-alpha, 4.0.0 pre-release, 3.9.x Wartung
• 2022-10 -> 2023-10: 5.0.0 pre-alpha, 4.x.0 Feature Releases, 3.9.x Wartung
• 2023-10 -> 2024-05: 5.0.0 pre-beta, 4.x.y Wartung
• 2024-05 -> 2024-10: 6.0.0 pre-alpha, 5.0.0 pre-release, 4.x.y Wartung
• ... usw.