Release-Kadenz für ein kleines Projekt: zeitbasierte Züge versus Release-wenn-bereit

Worum es geht

Es gibt zwei Familien von Kadenz. Zeitbasiert: Ein Release geht an einem festen Datum hinaus, unabhängig davon, was fertig ist. Das Rust-Buch beschreibt ein Zugmodell, bei dem alle sechs Wochen eine Beta von Nightly abzweigt und sechs Wochen später zu Stable wird; PEP 602 stellte Python auf einen jährlichen Releasezyklus mit Feature-Versionen jeden Oktober um; der Django-Release-Prozess hält fest, dass Feature-Releases einem zeitbasierten Zeitplan folgen, während Patch-Releases bei Bedarf herausgegeben werden. Feature-basiert: Ein Release erfolgt, sobald eine geplante Menge von Änderungen vollständig ist. Die Versionierung (Semantic Versioning, verlinkt) regelt, was die Nummer verspricht; die Kadenz regelt, wann eine Nummer erscheint.

Warum es wichtig ist

Das Rust-Buch liefert das Argument für Züge: Verpasst ein Feature ein Release, ist das nächste nahe, was den Druck verringert, unfertige Arbeit vor einer Deadline hineinzudrängen. Bei einem Projekt mit ein oder zwei Maintainern ist das entgegengesetzte Versagen dasjenige, auf das zu achten ist: Releases werden selten, weil jedes davon sich wie ein Ereignis anfühlt, sodass Korrekturen monatelang unveröffentlicht auf dem Main-Branch liegen bleiben und Nutzende gepatchte Forks betreiben.

So wird es angewendet

• Die beiden Release-Arten trennen. Patch-Releases gehen hinaus, sobald eine Korrektur fertig ist und die CI grün ist; Feature-Releases gehen in einem festgelegten Rhythmus hinaus oder sobald sich eine nennenswerte Änderung angesammelt hat, je nachdem, was das Projekt durchhalten kann.
• Die Richtlinie dort festhalten, wo Nutzende danach suchen (README oder Dokumentation): was ein Release auslöst, welche Linien unterstützt werden, und wo das Changelog liegt.
• Ein Release nur Minuten kosten lassen: ein Tag, ein generierter Changelog-Abschnitt, eine skriptgesteuerte Veröffentlichung. Eine Kadenz, die von einer manuellen Checkliste abhängt, wird übersprungen.
• Eine Freeze-Regel für Feature-Releases festlegen: Nach dem Schnitt gelangen nur noch Korrekturen in den Release-Branch, wie in der Rust-Beta-Periode.
• Mit dem Changelog ankündigen, nicht mit dem Tag; Leserinnen und Leser wollen wissen, was sich geändert hat und ob ein Upgrade sicher ist.

Stolpersteine

Eine Major-Version erhöhen, um Marketing statt Inkompatibilität zu signalisieren. Zeitbasierte Züge ohne automatisierte Tests werden zu geplanten Regressionen. Ein grosses Bündel nach einer langen Pause freizugeben macht das Bisektieren einer Regression für Nutzende teuer. Zulassen, dass aus "wir releasen, wenn es bereit ist" ein "wir haben dieses Jahr nichts releast" wird.