Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python Enhancement Proposals

PEP 407 – Neuer Release-Zyklus und Einführung von Langzeit-Support-Versionen

Autor:
Antoine Pitrou <solipsis at pitrou.net>, Georg Brandl <georg at python.org>, Barry Warsaw <barry at python.org>
Status:
Verschoben
Typ:
Prozess
Erstellt:
12-Jan-2012
Post-History:
17-Jan-2012
Inhaltsverzeichnis

Zusammenfassung

Die Festlegung eines Release-Zyklus für ein Open-Source-Projekt ist eine heikle Übung im Management widersprüchlicher Zwänge: Entwicklerressourcen, Verfügbarkeit von Freiwilligen für das Release-Management, Wartungsfreundlichkeit für Benutzer und Drittanbieter-Paketierer, schnelle Verfügbarkeit neuer Funktionen (und Verhaltensänderungen), Verfügbarkeit von Fehlerbehebungen, ohne neue Funktionen oder Verhaltensänderungen mit einzubringen.

Der aktuelle Release-Zyklus tendiert zur konservativen Seite. Er ist ausreichend für Leute, die Stabilität über Reaktionsfähigkeit schätzen. Dieses PEP ist ein Versuch, die Stabilität, die zu einem Markenzeichen von Python geworden ist, beizubehalten und gleichzeitig eine flüssigere Veröffentlichung von Funktionen anzubieten, indem die Idee von Langzeit-Support-Versionen eingeführt wird.

Umfang

Dieses PEP versucht nicht, die Wartungsperiode oder das Release-Schema für den 2.7-Zweig zu ändern. Nur 3.x-Versionen werden berücksichtigt.

Vorschlag

Unter dem vorgeschlagenen Schema gäbe es zwei Arten von Funktionsversionen (manchmal als „Nebenversionen“ bezeichnet, z. B. 3.2 oder 3.3): normale Funktionsversionen und Langzeit-Support (LTS)-Versionen.

Normale Funktionsversionen würden entweder keine oder höchstens eine Bugfix-Version erhalten; letztere nur, wenn zur Behebung kritischer Probleme erforderlich. Die Handhabung von Sicherheitspatches für diese Zweige muss noch entschieden werden.

LTS-Versionen würden regelmäßige Bugfix-Versionen erhalten, bis die nächste LTS-Version herauskommt. Danach würden sie in den Modus für Sicherheitspatches wechseln, bis zu einem von der Release-Leitung nach eigenem Ermessen festgelegten Enddatum.

Periodizität

Eine neue Funktionsversion würde alle X Monate veröffentlicht. Wir schlagen vorläufig X = 6 Monate vor.

LTS-Versionen wären eine von N Funktionsversionen. Wir schlagen vorläufig N = 4 vor.

Mit diesen Zahlen käme alle 24 Monate eine neue LTS-Version heraus und bliebe bis zur nächsten LTS-Version, 24 Monate später, unterstützt. Dies ähnelt leicht dem heutigen 18-monatigen Bugfix-Zyklus für jede Funktionsversion.

Vorabversionen (Pre-release versions)

Häufigere Funktionsveröffentlichungen bedeuten eine geringere Anzahl störender Änderungen pro Veröffentlichung. Daher kann die Anzahl der Vorabversionen (Alphas und Betas) erheblich reduziert werden. Zwei Alpha-Versionen und eine einzelne Beta-Version wären im Normalfall wahrscheinlich ausreichend. Die Anzahl der Release Candidates hängt wie üblich von der Anzahl der letzten Korrekturen vor der endgültigen Veröffentlichung ab.

Auswirkungen

Auswirkungen auf den Entwicklungszyklus

Mehr Funktionsveröffentlichungen könnten mehr Belastung für die Entwicklungs- und Release-Management-Teams bedeuten. Dies wird quantitativ durch die geringere Anzahl von Vorabversionen gemildert; und qualitativ durch die geringere Menge an störenden Änderungen (was weniger Potenzial für Brüche bedeutet). Die kürzere Feature-Freeze-Periode (nach dem ersten Beta-Build bis zur endgültigen Veröffentlichung) ist leichter zu akzeptieren. Die Eile, Funktionen kurz vor dem Feature-Freeze hinzuzufügen, sollte ebenfalls deutlich geringer sein.

Auswirkungen auf den Bugfix-Zyklus

Die Auswirkungen auf die Fehlerbehebung sollten bei den vorgeschlagenen Zahlen minimal sein. Die gleiche Anzahl von Zweigen wäre gleichzeitig für die Bugfix-Wartung geöffnet (zwei, bis 2.x beendet ist, dann einer).

Auswirkungen auf den Workflow

Der Workflow für neue Funktionen bliebe derselbe: Entwickler würden sie nur in den default-Branch einchecken.

Der Workflow für Fehlerbehebungen würde leicht aktualisiert: Entwickler würden Fehlerbehebungen in den aktuellen LTS-Branch (z. B. 3.3) einchecken und sie dann in den default-Branch mergen.

Wenn einige kritische Korrekturen für eine Nicht-LTS-Version benötigt werden, können sie vom aktuellen LTS-Branch zum Nicht-LTS-Branch übertragen werden, so wie Korrekturen heute von 3.x nach 2.7 portiert werden.

Auswirkungen auf die Community

Personen, die Wert auf Stabilität legen, können sich einfach an den LTS-Veröffentlichungen orientieren, die mit den vorgeschlagenen Zahlen einen ähnlichen Support-Zyklus (sowohl in Dauer als auch in Stabilität) bieten würden.

Personen, die Wert auf Reaktionsfähigkeit und Zugang zu neuen Funktionen legen (ohne das Risiko einzugehen, Alpha-Versionen oder Mercurial-Snapshots zu installieren), würden von dem neuen Release-Zyklus deutlich mehr profitieren als bisher.

Personen, die neue Funktionen oder Verbesserungen beitragen möchten, wären motivierter, dies zu tun, da ihre Beiträge schneller für normale Benutzer verfügbar sein würden. Außerdem macht eine kürzere Feature-Freeze-Periode die Interaktion mit Beitragsleistenden für Funktionen weniger umständlich.

Diskussion

Dies sind offene Fragen, die während der Diskussion geklärt werden sollten

  • Entscheiden Sie über X (Monate zwischen Funktionsveröffentlichungen) und N (Funktionsveröffentlichungen pro LTS-Veröffentlichung) wie oben definiert.
  • Sind bei gegebenen Werten von X und N die Richtlinien „keine Bugfix-Veröffentlichungen“ für Nicht-LTS-Versionen machbar?
  • Wie lautet die Richtlinie für Sicherheitspatches?
  • Beschränken Sie neue Syntax und ähnliche Änderungen (d. h. alles, was durch PEP 3003 verboten war) auf LTS-Versionen?
  • Welche Auswirkungen hat dies auf Paketierer wie Linux-Distributionen?
  • Wie werden Release-Versionsnummern oder anderes identifizierendes und Marketingmaterial den Benutzern klar machen, welche Versionen normale Funktionsversionen und welche LTS-Versionen sind? Wie verwalten wir die Erwartungen der Benutzer?
  • Bedeutet der schnellere Release-Zyklus, dass wir eines Tages 3.10 und höher erreichen könnten? Einige Leute äußerten die stillschweigende Erwartung, dass Versionsnummern immer in eine Dezimalstelle passen.

Eine Community-Umfrage oder -Befragung zur Sammlung von Meinungen aus der breiteren Python-Community wäre wertvoll, bevor eine endgültige Entscheidung getroffen wird.

Quelle: https://github.com/python/peps/blob/main/peps/pep-0407.rst

Zuletzt geändert: 2025-02-01 08:59:27 GMT