Siebzehn Monate zur Entwicklung einer Feature-Version

Dieses PEP schlägt vor, dass Python 3.X.0 etwa 17 Monate lang entwickelt wird

• Die ersten *fünf Monate* überschneiden sich mit den Beta- und Release-Candidate-Phasen von Python 3.(X-1).0 und sind daher nicht versioniert.
• Die nächsten *sieben Monate* werden für versionierte Alpha-Releases verwendet, bei denen schrittweise neue Features hinzugefügt und Fehler behoben werden.
• Die folgenden *drei Monate* werden für vier versionierte Beta-Releases verwendet, bei denen **keine neuen Features** mehr hinzugefügt werden können, aber immer noch Fehler behoben werden.
• Die letzten *zwei Monate* werden für zwei Release Candidates (oder mehr, falls erforderlich) verwendet und enden mit der Veröffentlichung der endgültigen Version von Python 3.X.0.

2 Jahre voller Support, 3 weitere Jahre mit Sicherheitsupdates

Nach der Veröffentlichung von Python 3.X.0 wird die 3.X-Serie fünf Jahre lang gepflegt

• Während der *ersten vierundzwanzig Monate* (2 Jahre) erhält sie Bugfix-Updates und volle Releases (Quellen und Installer für Windows und macOS) werden ungefähr alle zwei Monate veröffentlicht.
• Für die nächsten *sechsunddreißig Monate* (3 Jahre) erhält sie Sicherheitsupdates, und es werden nach Bedarf nur Quellcode-Releases veröffentlicht (keine feste Kadenz).
• Das letzte Release nur mit Quellcode wird *fünf Jahre* nach 3.X.0 veröffentlicht.

Hinweis: 2 Jahre voller Support beginnen mit Python 3.13. Python-Versionen 3.9 - 3.12 arbeiten mit einem Kalender, der 1½ Jahre vollen Support und danach weitere 3½ Jahre Sicherheitsupdates vorsieht.

Jährliche Release-Kadenz

Die Feature-Entwicklung von Python 3.(X+1).0 beginnt, sobald Python 3.X.0 Beta 1 veröffentlicht wird. Dies schafft einen zwölfmonatigen Abstand zwischen den Python-Feature-Versionen.

Deprecations

Die aktuelle Richtlinie für Breaking Changes geht davon aus, dass mindestens zwei Releases vergehen, bevor eine veraltete Funktion aus Python entfernt oder ein `__future__`-Verhalten standardmäßig aktiviert wird. Dies ist in PEP 387 dokumentiert.

Dieses PEP schlägt vor, diese Richtlinie von **mindestens** zwei Releases beizubehalten, bevor eine Breaking Change vorgenommen wird.

Die Amtszeit des Steering Council

Die aktuelle Formulierung in PEP 13 besagt, dass „ein neuer Rat nach jedem Feature-Release gewählt wird“. Dieses PEP schlägt vor, diese Richtlinie beizubehalten, da dies zu einem konsistenten Wahlplan führt.

Die Amtszeit des Release Managers

Die aktuelle, undokumentierte Konvention ist, dass ein einzelner Release Manager zwei Feature-Releases von Python betreut. Dieses PEP schlägt vor, diese Richtlinie beizubehalten und die Amtszeit mit Zustimmung des Steering Council und des Cabal of Release Managers auf weitere Releases auszudehnen.

Insbesondere, da dieses PEP vom aktiven Release Manager verfasst wurde und seine Wirkung die Amtszeit des Release Managers verkürzen würde, ist der Autor bereit, die Veröffentlichung einer dritten Feature-Reihe zu übernehmen, um die Störung auszugleichen.

Non-goals

Die Einführung eines jährlichen Release-Kalenders ermöglicht einen natürlichen Übergang zur Kalender-Versionierung, beispielsweise durch die Benennung von Python 3.9 als „Python 3.20“, da es im Oktober '20 veröffentlicht wird und so weiter („Python 3.23“ wäre das im Oktober '23 veröffentlichte).

Während die einfache Umstellung auf Kalender-Versionierung als Vorteil eines jährlichen Release-Zyklus betrachtet werden kann, befürwortet dieses PEP keine Änderung der Art und Weise, wie Python versioniert wird, oder spricht sich dagegen aus. Sollte der jährliche Release-Zyklus angenommen werden, wird die Frage der Versionierung in einem separaten PEP behandelt.

Nicht-Risiken

Diese Änderung verkürzt nicht den aktuell dokumentierten Support-Kalender für ein Python-Release, sowohl in Bezug auf Bugfix-Releases als auch auf Sicherheitsupdates.

Diese Änderung beschleunigt nicht die Entwicklungsgeschwindigkeit. Python wird nicht schneller inkompatibel oder entwickelt schneller neue Features. Es werden lediglich die Features schrittweiser veröffentlicht, sobald sie entwickelt werden.

Folglich ermöglicht diese Änderung zwar, dass Benutzer viel schneller upgraden können, zwingt sie aber nicht dazu. Wenn sie beispielsweise alle zwei Releases upgraden, wird ihre Erfahrung mit Python der aktuellen Situation ähneln.

Risiken

Die Testmatrix

Dies erhöht letztendlich die Testmatrix für Bibliotheks- und Anwendungsmaintainer, die alle aktiv unterstützten Python-Versionen mit ein bis zwei zusätzlichen testen möchten.

Die Phase der „erweiterten Bugfix-Unterstützung nach Ermessen des Release Managers“ des aktuellen Release-Zyklus ist nicht kodifiziert. Tatsächlich besagt PEP 101 derzeit, dass nach der Veröffentlichung von Python 3.(X+1).0 nur noch ein letztes Bugfix-Release für Python 3.X.0 durchgeführt wird. In der Praxis überschnitten sich jedoch mindestens die letzten vier Versionen von Python 3 für etwa sechs Monate mit stabilen Releases der nächsten Version. Abbildung 2 enthält diese Informationen, um zu zeigen, dass die Überschneidung zwischen stabilen Versionen mit der 12-monatigen Release-Kadenz nichts Neues sein wird.

Abgelehnte Ideen