Reduzierung der Größe von Funktionsbereitstellungspartien

Wenn mehrere große Änderungen zusammen geliefert werden, kann eine komplexe Untersuchung erforderlich sein, um die Ursache etwaiger neuer Probleme zu ermitteln. Große Batch-Größen erhöhen auch die Wahrscheinlichkeit, dass Probleme auftreten, da sie größere Teile relativ ungetesteten Codes enthalten.

Der einfachste Weg, diese Untersuchungen zu vereinfachen und die Wahrscheinlichkeit zu verringern, dass Benutzer auf Probleme stoßen, besteht darin, die Größe der ausgelieferten Batches zu reduzieren.

PEP 602 schlägt vor, dieses Problem durch den einfachen Ansatz zu lösen, die typische Batch-Größe von CPython um 50% zu reduzieren und jedes Mal 12 Monate Änderungen auszuliefern, anstatt 18+ Monate Änderungen anzuhäufen.

PEP 605 schlägt vor, dieses Problem durch regelmäßige Lieferung von 2 Monaten Änderungen an eine Teilmenge der Python-Benutzerbasis zu lösen, die sich für die Ausführung eines fortlaufenden Streams von Beta-Releases entscheidet (ähnlich der Ausführung von Windows Insider-Builds anstelle der Windows-Retail-Version oder der Ausführung von Debian Testing anstelle von Debian Stable).

Reduzierung der Latenz bei der Funktionsbereitstellung

Wenn nur stabile Releases eine signifikante Benutzerakzeptanz finden und eine lange Zeit zwischen stabilen Releases vergeht, entsteht eine unglaublich starke Versuchung für Entwickler, Änderungen in stabile Releases einzubringen, bevor sie wirklich für den allgemeinen Gebrauch bereit sind.

PEP 602 schlägt vor, dieses Problem zu lösen, indem die Zeitspanne zwischen stabilen Releases auf 12 Monate anstatt auf 18 Monate verkürzt wird.

PEP 605 schlägt vor, dieses Problem zu lösen, indem aktiv eine Community von Python-Benutzern geschaffen wird, die regelmäßig CPython-Beta-Releases installieren und verwenden. Dies bietet einen Anreiz für Kernentwickler, Änderungen früher im Vorabveröffentlichungszyklus zu liefern, um Feedback zu erhalten, bevor die Funktion in einer stabilen Version gesperrt wird.

Abstimmung des Release-Zyklus mit dem Kalenderjahr

Obwohl der aktuelle Release-Zyklus nominell 18-24 Monate beträgt, lag er in der Praxis durchweg am unteren Ende dieses Bereichs. Das bedeutet, dass sich die Zieltermine für Vorabversionen und endgültige Versionen von Release zu Release verschieben, und die einzige Möglichkeit, sich daran zu erinnern, besteht darin, entweder die Release-PEP zu konsultieren oder diese Daten Ihrem Kalender hinzuzufügen. Dies ist sowohl für einzelne Freiwillige als auch für Unternehmensbeitragende ärgerlich und erschwert die Abstimmung mit Veranstaltungen wie PyCon US (typischerweise April/Mai) und den nun jährlichen Kernentwicklungs-Sprints (typischerweise im September).

PEP 602 schlägt vor, dieses Problem zu lösen, indem jedes Jahr im Oktober eine neue Version veröffentlicht wird und der Kalender für Vorabversionen auf dieser Grundlage erstellt wird.

PEP 605 schlägt vor, dieses Problem zu lösen, indem zwischen Release-Jahren (in denen eine neue stabile Version im August veröffentlicht wird) und Nicht-Release-Jahren (in denen nur Wartungsversionen und neue fortlaufende Beta-Versionen veröffentlicht werden) abgewechselt wird.

Verbesserung des Feedback-Zyklus für das Design von Vorabversionen

Eine der Herausforderungen bei der Gestaltung von Änderungen am Kerninterpreter und den Standardbibliotheks-APIs besteht darin, dass die Benutzerbasis, die Feedback zu Nightly-Builds und den aktuellen Vorabversionen geben kann, relativ begrenzt ist. Das bedeutet, dass viel Benutzerfeedback erst eingeht, nachdem ein API-Design bereits in einer vollständigen X.Y.0-Version ausgeliefert wurde.

Wenn es sich bei der API um eine reguläre API handelt, bedeutet dies, dass es buchstäblich Jahre dauern kann, bis Designfehler, die zu diesem Zeitpunkt identifiziert wurden, behoben sind. Das Markieren von APIs als provisorisch bietet nominell eine Möglichkeit, diese Einschränkung zu vermeiden, aber die tatsächliche Nutzung dieser Freiheit verursacht andere Probleme.

PEP 602 schlägt vor, dieses Problem zu lösen, indem die Alpha-Phase unmittelbar nach der vorherigen stabilen Version beginnt.

PEP 605 schlägt vor, dieses Problem zu lösen, indem die Nutzung von CPython-Vorabversionen für produktive Workloads (nicht nur für Kompatibilitätstests von Bibliotheken und Anwendungen) aktiv gefördert wird und der Prozess der Verwaltung von Vorabversionen bei Bedarf angepasst wird, um dies zu einer vernünftigen Vorgehensweise zu machen.

(Hinweis: Einige APIs der Standardbibliothek können zunächst als Teil separat versionierter Pakete über PyPI ausgeliefert und erst später in die Standardbibliothek integriert werden. Dieser Abschnitt befasst sich eher mit den Low-Level-APIs und Nicht-Bibliotheksfunktionen, bei denen dieser Ansatz zum Erhalt von frühem Design-Feedback nicht zutrifft.)

Auswirkungen auf Benutzer und Wiederverteiler, die einige Releases bereits überspringen

Es ist bereits der Fall, dass nicht alle Benutzer und Wiederverteiler auf jede veröffentlichte CPython-Release-Serie aktualisieren (z. B. überspringen Debian Stable und Ubuntu LTS manchmal Releases aufgrund der Diskrepanz zwischen ihren 24-monatigen Release-Zyklen und dem typischerweise 18-monatigen Zyklus von CPython).

Die schnellere 12-monatige Release-Kadenz in PEP 602 bedeutet, dass Benutzer in dieser Kategorie möglicherweise zwei Releases überspringen, wo sie zuvor nur eines übersprungen hätten. Die verlängerte Vorankündigungsfrist für Deprecations bedeutet jedoch, dass das Überspringen eines einzelnen Releases keine verpassten Deprecations-Warnungen mehr zur Folge haben sollte.

Die langsamere 24-monatige Release-Kadenz in PEP 605 kann einige der Benutzer, die historisch in diese Kategorie fallen, in die Kategorie "Auf jedes stabile Release aktualisieren" verschieben.

Auswirkungen auf Benutzer und Wiederverteiler, die auf jedes Release aktualisieren

Viele Python-Benutzer installieren niemals eine Vorabversion, aktualisieren aber irgendwann nach der Veröffentlichung auf jede stabile Release-Serie.

PEP 602 zielt darauf ab, die potenziellen negativen Auswirkungen auf Mitglieder dieser Gruppe abzumildern, indem der minimale Abstand zwischen den Releases auf 12 Monate begrenzt und die 18-monatige vollständige Support-Periode für jedes Release beibehalten wird.

Die Beibehaltung der 18-monatigen vollständigen Support-Periode für jeden Release-Zweig bedeutet, dass die Zweige ungefähr die gleiche Zeit im vollständigen Support-Modus und im Nur-Sicherheitsfix-Modus verbringen werden wie jetzt (~18 Monate bzw. ~42 Monate).

PEP 605 zielt darauf ab, die potenziellen negativen Auswirkungen auf Mitglieder dieser Gruppe abzumildern, indem die Nutzung während der Vorabveröffentlichungsphase erhöht wird, um stabilere finale Versionen mit breiterer Ökosystem-Unterstützung beim Start zu erzielen.

Mit einer 24-monatigen Release-Kadenz wird jeder Release-Zweig proportional mehr Zeit im vollständigen Support-Modus und weniger Zeit im Nur-Sicherheitsfix-Modus verbringen (~24 Monate und ~36 Monate, jeweils).

Die vollständige Diskussion der Auswirkungen auf diese Gruppe ist den einzelnen PEPs überlassen.

Auswirkungen auf Benutzer und Wiederverteiler von CPython-Nightly-Builds

Trotz der Schwierigkeiten tun dies bereits einige Benutzer und Wiederverteiler, indem sie den CPython-Master-Zweig direkt verwenden oder veröffentlichen.

Weder PEP 602 noch PEP 605 sollten diese Gruppe direkt beeinflussen, aber der Vorschlag für einen fortlaufenden Release-Stream in PEP 605 zielt darauf ab, die Hürden für mehr Benutzer, diese Art der Nutzung zu übernehmen, zu senken, indem sie den getesteten fortlaufenden Beta-Stream übernehmen können, anstatt den Master-Zweig direkt verwenden zu müssen.

Auswirkungen auf Maintainer von Drittanbieterbibliotheken

Für Maintainer von Drittanbieterbibliotheken ist die Hauptquelle für Support-Komplexität die *Anzahl* der verschiedenen Python-Versionen, die weit verbreitet sind.

PEP 602 zielt darauf ab, die potenziellen negativen Auswirkungen auf Mitglieder dieser Gruppe abzumildern, indem der minimale Abstand zwischen den vollständigen Releases auf 12 Monate begrenzt wird.

PEP 605 zielt darauf ab, die potenziellen negativen Auswirkungen auf Mitglieder dieser Gruppe abzumildern, indem der Abstand zwischen den vollständigen Releases auf 24 Monate erhöht, die aktuelle Richtlinie beibehalten wird, jeden Release-Zweig kurz nach der Veröffentlichung seines Nachfolgers in den Modus "Nur Sicherheitsfixes" zu versetzen, und das Namensschema "Beta" für den neuen fortlaufenden Release-Stream beibehalten wird (zumindest für den Python 3.9 Release-Zyklus).

Die vollständige Diskussion der Auswirkungen auf diese Gruppe ist den einzelnen PEPs überlassen.