Mehrere Release-Linien pflegen: welche Fixes wohin gehören

Worum es geht

Eine Richtlinie zu unterstützten Versionen beantwortet «bekommt Version A.B diesen Fix?», bevor jemand fragt. Sie hat zwei Teile: eine Tabelle der Release-Linien mit ihrem Status und ihren Daten, und Backport-Regeln je Fix-Klasse. Der Django-Release-Prozess ist ein kompaktes Beispiel: Der Hauptzweig erhält Features; das letzte Feature-Release erhält Fixes für Release-Blocker (Sicherheit, Datenverlust, Abstürze, grössere Fehler in neuen Funktionen, Regressionen); Sicherheits- und Datenverlust-Fixes gehen auf den Hauptzweig, die letzten zwei Feature-Zweige und jeden unterstützten Long-Term-Support-Zweig; Dokumentationsfixes werden grosszügiger zurückportiert. PEP 602 beschreibt die Python-Reihe als fünf Jahre gepflegt: Bugfix-Releases für die ersten zwei, danach reine Sicherheits-Quell-Releases für drei weitere (ab Python 3.13). Das Rust-Buch nennt das entgegengesetzte Extrem: Nur die jeweils neueste Stable-Version wird unterstützt, sodass jede Version sechs Wochen lang unterstützt wird.

Warum es wichtig ist

Nutzende können nicht nach dem Zeitplan des Projekts aktualisieren, und eine massgebliche Person kann nicht jede Linie für immer pflegen. Ohne eine schriftliche Regel wird jede Anfrage nach einem Backport zu einer Verhandlung, und Sicherheitsfixes landen stillschweigend nur auf dem Hauptzweig, während Nutzende der vorherigen Linie glauben, abgedeckt zu sein.

So wird es angewendet

• Die Tabelle dort veröffentlichen, wo Nutzende nachsehen: Linie, Status, erstes Release, geplantes End of Life. Einen Zweig je unterstützter Linie führen, einheitlich benannt (Django verwendet stable/A.B.x).
• Standard für ein kleines Projekt: Das neueste Feature-Release erhält alle Fixes; das vorherige erhält Sicherheitsfixes für eine festgelegte Dauer; sonst nichts. Nur erweitern, wenn eine zweite massgebliche Person vorhanden ist.
• Per Cherry-Pick zurückportieren, mit dem ursprünglichen Commit-Verweis in der Meldung, und den Backport veröffentlichen; ein Fix auf einem Zweig ohne Release hilft niemandem.
• Die CI-Matrix auf unterstützte Linien beschränken; eine nicht unterstützte Linie, die weiterhin getestet wird, lädt zu Anfragen ein, sie zu reparieren.
• End of Life im Voraus im Changelog ankündigen und die Linie am festgelegten Datum aus der Tabelle entfernen.
• Langzeitunterstützung nur anbieten, wenn die Jahre auch tatsächlich versprochen werden können; eine aufgegebene LTS-Kennzeichnung ist schlimmer als keine.

Stolpersteine

Features unter dem Namen von Fixes zurückportieren, was eine stabile Linie in eine zweite Entwicklungslinie verwandelt. Ein Sicherheitsproblem nur auf dem Hauptzweig beheben. Die CI-Matrix mit jeder unterstützten Version jeder Abhängigkeit wachsen lassen, bis nichts mehr grün ist. Vergessen, dass auch die Dokumentation für alte Linien erreichbar bleiben muss.