Release Please: automatisierte Release-PRs aus Conventional Commits

Release-PR statt Sofort-Release

Release Please automatisiert drei Aufgaben: Changelog-Generierung, Erstellung von GitHub-Releases und Versionssprünge. Statt bei jedem Merge auf den Standard-Branch ein Release zu schneiden, wird ein Release-PR gepflegt, der mit weiteren Merges aktualisiert wird. Das Mergen dieses PRs löst eine Changelog-Aktualisierung, einen Versions-Tag und ein GitHub-Release aus. Der Status eines Release-PRs wird über Labels verfolgt: `autorelease: pending` vor dem Merge, `autorelease: tagged` nach Merge und Tagging, `autorelease: snapshot` für Snapshot-Versionssprünge und `autorelease: published` für ein veröffentlichtes Release, das das Tool nicht automatisch hinzufügt, aber als Konvention empfiehlt. release-please bleibt dabei auf die im README beschriebenen Aufgaben begrenzt. Für die technische Beurteilung sind die genannten Dateien, Befehle und Schnittstellen wichtiger als die Sternezahl; nicht dokumentierte Eigenschaften sollten nicht vorausgesetzt werden. Im Abschnitt „Release-PR statt Sofort-Release“ ist für release-please besonders zu prüfen, welche konkrete Eingabe auf welche Ausgabe trifft. Diese Einordnung ergänzt keine Funktion: Sie hält die Entscheidung an der Projektbeschreibung fest und markiert nicht dokumentierte Betriebsannahmen als offen.

Conventional Commits als Eingang

Release Please liest die Git-Historie und sucht nach Conventional-Commit-Nachrichten. Die wichtigsten Präfixe sind `fix:` für Patches, `feat:` für Minor-Versionen und jedes Präfix mit `!` für Breaking Changes, die zu einer Major-Version führen. Eine veröffentlichbare Einheit ist ein Commit mit dem Präfix `feat`, `fix` oder `deps` auf dem Standard-Branch. Einige Sprachen konfigurieren zusätzliche Präfixe, z.B. `docs` für Java und Python. Chore- und Build-Commits sind keine veröffentlichbaren Einheiten. release-please bleibt dabei auf die im README beschriebenen Aufgaben begrenzt. Für die technische Beurteilung sind die genannten Dateien, Befehle und Schnittstellen wichtiger als die Sternezahl; nicht dokumentierte Eigenschaften sollten nicht vorausgesetzt werden. Im Abschnitt „Conventional Commits als Eingang“ ist für release-please besonders zu prüfen, welche konkrete Eingabe auf welche Ausgabe trifft. Diese Einordnung ergänzt keine Funktion: Sie hält die Entscheidung an den Angaben zu Conventional Commits als Eingang fest und markiert nicht dokumentierte Betriebsannahmen als offen.

Release-As und Commit-Overrides

Um einen Release-PR für eine bestimmte Version zu öffnen, fügen Sie `Release-As: x.x.x` in den Body eines Commits auf dem Haupt-Branch ein. Das README zeigt ein Beispiel mit leerem Commit, das eine Nachricht mit `chore: release 2.0.0` und `Release-As: 2.0.0` erzeugt. Um die Release-Notizen eines gemergten PRs zu ändern, bearbeiten Sie den PR-Body und fügen einen `BEGIN_COMMIT_OVERRIDE`-Abschnitt mit den Ersatz-Commit-Nachrichten ein, gefolgt von `END_COMMIT_OVERRIDE`. Beim nächsten Lauf wird dieser Override verwendet. Dies funktioniert nicht bei normalen Merges, da release-please nicht erkennen kann, auf welche Commits der Override angewendet werden soll; Squash-Merging wird empfohlen. release-please bleibt dabei auf die im README beschriebenen Aufgaben begrenzt. Für die technische Beurteilung sind die genannten Dateien, Befehle und Schnittstellen wichtiger als die Sternezahl; nicht dokumentierte Eigenschaften sollten nicht vorausgesetzt werden. Im Abschnitt „Release-As und Commit-Overrides“ ist für release-please besonders zu prüfen, welche konkrete Eingabe auf welche Ausgabe trifft. Diese Einordnung ergänzt keine Funktion: Sie hält die Entscheidung an den Angaben zu Release-As und Commit-Overrides fest und markiert nicht dokumentierte Betriebsannahmen als offen.

Labels bei ausbleibendem PR

Wenn Release Please keinen Release-PR erstellt hat, bietet das README drei Schritte zur Fehlerbehebung. Erstens bestätigen Sie, dass der Standard-Branch seit dem letzten Release veröffentlichbare Einheiten enthält; ein Commit mit `feat`, `fix` oder `deps` ist erforderlich. Zweitens prüfen Sie auf veraltete `autorelease: pending`- oder `autorelease: triggered`-Labels auf alten PRs; GitHub-API-Fehler können diese Labels hinterlassen und neue Release-PRs blockieren. Entfernen Sie sie, wenn sicher ist, dass kein Release aussteht. Drittens führen Sie release-please erneut aus. Für die GitHub-Anwendung fügen Sie das Label `release-please:force-run` zum gemergten Pull-Request hinzu; für die Action wiederholen Sie den fehlgeschlagenen Workflow-Lauf. release-please bleibt dabei auf die im README beschriebenen Aufgaben begrenzt. Für die technische Beurteilung sind die genannten Dateien, Befehle und Schnittstellen wichtiger als die Sternezahl; nicht dokumentierte Eigenschaften sollten nicht vorausgesetzt werden. Im Abschnitt „Labels bei ausbleibendem PR“ ist für release-please besonders zu prüfen, welche konkrete Eingabe auf welche Ausgabe trifft. Diese Einordnung ergänzt keine Funktion: Sie hält die Entscheidung an den Angaben zu Labels bei ausbleibendem PR fest und markiert nicht dokumentierte Betriebsannahmen als offen.

Strategien für Monorepos

Release Please enthält Release-Typ-Konfigurationen für viele Ökosysteme: Bazel-Module, Dart, Elixir, Go, Helm, Java, Maven, Node, Expo, OCaml, PHP, Python, R, Ruby, Rust, SFDX, simple (version.txt) und Terraform-Module. Jeder Typ sucht nach bestimmten Dateien, z.B. package.json für Node, pubspec.yaml für Dart oder pyproject.toml für Python. Rust-Workspaces erfordern einen manifestgesteuerten Release und das cargo-workspace-Plugin. Die Tabelle im README verlinkt Beispiele für mehrere Strategien. release-please bleibt dabei auf die im README beschriebenen Aufgaben begrenzt. Für die technische Beurteilung sind die genannten Dateien, Befehle und Schnittstellen wichtiger als die Sternezahl; nicht dokumentierte Eigenschaften sollten nicht vorausgesetzt werden. Im Abschnitt „Strategien für Monorepos“ ist für release-please besonders zu prüfen, welche konkrete Eingabe auf welche Ausgabe trifft. Diese Einordnung ergänzt keine Funktion: Sie hält die Entscheidung an den Angaben zu Strategien für Monorepos fest und markiert nicht dokumentierte Betriebsannahmen als offen.

Action, CLI und Anpassung

Die empfohlene Methode, Release Please auszuführen, ist als GitHub-Action, mit Installations- und Konfigurationsanweisungen im Repository googleapis/release-please-action. Es kann auch als CLI ausgeführt werden, dokumentiert in docs/cli.md. Um ein bestehendes Repository anzubinden, ist der einfachste Weg, eine Manifest-Konfiguration zu bootstrappen. Anpassungsoptionen sind in docs/customizing.md abgedeckt, und Monorepo-Unterstützung über Manifest-Konfiguration in docs/manifest-releaser.md. Das README listet keine spezifischen Konfigurationsoptionen auf, sondern verweist nur auf diese Dokumente. release-please bleibt dabei auf die im README beschriebenen Aufgaben begrenzt. Für die technische Beurteilung sind die genannten Dateien, Befehle und Schnittstellen wichtiger als die Sternezahl; nicht dokumentierte Eigenschaften sollten nicht vorausgesetzt werden. Im Abschnitt „Action, CLI und Anpassung“ ist für release-please besonders zu prüfen, welche konkrete Eingabe auf welche Ausgabe trifft. Diese Einordnung ergänzt keine Funktion: Sie hält die Entscheidung an den Angaben zu Action, CLI und Anpassung fest und markiert nicht dokumentierte Betriebsannahmen als offen.

Node-Versionen und Apache 2.0

Die Bibliothek folgt dem Node.js-Release-Zeitplan und unterstützt alle aktuellen aktiven und Wartungsversionen. Legacy-Versionen sind über npm-Dist-Tags wie `legacy-8` verfügbar, aber sie sind Best-Effort: nicht in CI getestet, Sicherheitspatches werden möglicherweise nicht zurückportiert und Abhängigkeiten werden nicht aktualisiert. Das Projekt folgt Semantic Versioning. Es ist unter Apache 2.0 lizenziert. Das README stellt klar, dass dies kein offizielles Google-Produkt ist. Der Lizenzauszug gewährt dauerhafte, weltweite, nicht-exklusive, gebührenfreie Lizenzen für Urheber- und Patentrechte, geht aber nicht auf Support, Garantie oder Sicherheit ein. release-please bleibt dabei auf die im README beschriebenen Aufgaben begrenzt. Für die technische Beurteilung sind die genannten Dateien, Befehle und Schnittstellen wichtiger als die Sternezahl; nicht dokumentierte Eigenschaften sollten nicht vorausgesetzt werden. Im Abschnitt „Node-Versionen und Apache 2.0“ ist für release-please besonders zu prüfen, welche konkrete Eingabe auf welche Ausgabe trifft. Diese Einordnung ergänzt keine Funktion: Sie hält die Entscheidung an den Angaben zu Node-Versionen und Apache 2.0 fest und markiert nicht dokumentierte Betriebsannahmen als offen.

Redaktionelles Fazit

Geeignet ist release-please für Teams, deren Aufgabe genau zur dokumentierten Schnittstelle passt. Ungeeignet ist es als Ersatz für nicht beschriebene Funktionen. Prüfen Sie zuerst die README-Pfade und den vorgesehenen Einstieg von release-please; erst danach sollte ein produktiver Einsatz entschieden werden.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes