Thema: release-management
-
Tags und Releases: Lightweight- versus annotierte Tags und wie sie sich verbreiten
Ein Lightweight-Tag ist nur ein Name für einen Commit; ein annotierter Tag ist ein eigenes Objekt mit Tagger, Datum, Nachricht und optionaler Signatur – deshalb ignoriert git describe Lightweight-Tags standardmässig, und deshalb sollten Releases annotierte oder signierte Tags verwenden; Tags werden nicht zusammen mit Branches gepusht, ausser mit --follow-tags oder --tags, und ein veröffentlichter Tag sollte nie verschoben werden.
-
Cherry-Picking: wann es passt und was es die Historie kostet
git cherry-pick spielt die Änderung eines Commits als neuen Commit mit anderer ID nach; es ist das richtige Werkzeug, um einen Fix auf einen Wartungs-Branch zurückzuportieren oder einen einzelnen Commit aus einem aufgegebenen Branch zu retten, doch jedes Pick erzeugt ein Duplikat, das Merges nicht erkennen können, daher den Ursprung mit -x festhalten und mergen statt picken, wenn der ganze Branch gewollt ist.
-
Release-Kadenz für ein kleines Projekt: zeitbasierte Züge versus Release-wenn-bereit
Eine Versionsnummer sagt, was ein Release verspricht; eine Kadenz-Richtlinie sagt, wann Releases stattfinden. Rust liefert alle sechs Wochen ein Stable-Release aus einem Nightly-Beta-Stable-Zug, Python wechselte mit PEP 602 zu einem jährlichen Feature-Release, und Django gibt Feature-Releases nach einem zeitbasierten Zeitplan heraus, mit Patch-Releases bei Bedarf. Ein kleines Projekt kann diese Form übernehmen: Feature-Releases nach Kalender oder sobald sich etwas Nennenswertes angesammelt hat, Patch-Releases, sobald eine Korrektur fertig ist.
-
Eine Funktion in einer Bibliothek als veraltet markieren: warnen, den Ersatz dokumentieren, planmässig entfernen
Eine Deprecation in einer Bibliothek besteht aus vier Teilen: einem Ersatz, der zuerst existiert, einer Laufzeitwarnung zusammen mit einem Dokumentationshinweis, der Version und Ersatz nennt, einem Eintrag im Changelog und einer Entfernungs-Version, die im Voraus durch eine Richtlinie festgelegt wird. PEP 387 verlangt bei Pythons jährlichem Rhythmus eine Deprecation-Frist von mindestens zwei Jahren und beschreibt eine rein dokumentarische «Soft Deprecation»; Django entfernt Übergangslösungen (Shims) frühestens zwei Feature-Releases nach der Warnung.
-
Conventional Commits: maschinenlesbare Commit-Typen
Die Spezifikation Conventional Commits fügt Commit-Nachrichten ein typisiertes Präfix (feat, fix und andere) sowie Markierungen für Breaking Changes hinzu, damit sich Changelogs und Versionssprünge automatisch ableiten lassen.
-
Semantic Versioning: was eine Versionsnummer verspricht
Semantic Versioning 2.0.0 kodiert Kompatibilitätsversprechen in MAJOR.MINOR.PATCH und definiert Suffixe für Vorabversionen und Build-Metadaten; es funktioniert nur, wenn die öffentliche API deklariert ist.
-
API-Versionierung: wann und wie Kompatibilität gebrochen wird
Die meisten Änderungen lassen sich additiv gestalten; eine neue Hauptversion ist das letzte Mittel und verdoppelt die zu unterstützende Fläche. In Pfad oder Medientyp versionieren, die Kompatibilitätsregeln dokumentieren und vor dem Entfernen als veraltet markieren.
-
Mehrere Release-Linien pflegen: welche Fixes wohin gehören
Eine Support-Richtlinie ist eine Tabelle der Release-Linien mit je einem Status (Feature, Bugfix, nur Sicherheit, End of Life) und einer Regel, welche Fix-Klassen auf welche Linien zurückportiert werden. Python pflegt eine Reihe mit Bugfix-Releases für zwei Jahre und reinen Sicherheits-Releases für drei weitere; Django portiert kritische Fixes auf das letzte Feature-Release zurück und Sicherheits- sowie Datenverlust-Fixes auf die letzten zwei plus die Long-Term-Support-Linien; Rust unterstützt nur die jeweils neueste Stable-Version. Ein kleines Projekt sollte die Tabelle veröffentlichen und standardmässig das engste Versprechen abgeben, das es halten kann.
-
Ein Änderungsprotokoll für Menschen führen
Ein Änderungsprotokoll ist eine kuratierte, chronologisch geordnete Liste bemerkenswerter Änderungen pro Version; Keep a Changelog definiert eine kleine Struktur (Added, Changed, Deprecated, Removed, Fixed, Security) sowie einen Abschnitt Unreleased.
Maschinenlesbar: JSON