Kontext
Bei Layer87 wird gerade erhoben, wie ein drittes Release-Verfahren (CHANGELOG-gesteuert, aus Layer87/core-ng) in Layer87/arcon-hub eingerichtet werden könnte — Details in Layer87/arcon-hub#460 und im Arcon-Standard STD-release-procedures (org-weit, aktuell pending_review).
relctl kennt heute zwei Versionsschemata:
- SemVer (Default): Bump aus dem Branch-Präfix des gemergten PRs (
feature/, fix/, major/ …)
- CalVer:
YYYY.MM.DD.N, aus lokalen Git-Tags berechnet
Beide leiten die Version aus etwas ab, das vor dem Release feststeht, ohne dass jemand sie explizit hinschreibt. Das CHANGELOG-gesteuerte Verfahren aus core-ng tut das Gegenteil bewusst: die Version steht in einer ## X.Y.Z — YYYY-MM-DD-Überschrift, die ein Mensch (oder ein Release-PR) selbst in CHANGELOG.md einträgt — der Merge dieses PRs ist die Veröffentlichung. Es ist kein technisch abgeleiteter, sondern ein kuratierter, im Review sichtbarer Wert.
Die Frage, die dieses Issue stellt
Sollte relctl ein drittes Versionsschema bekommen — nennen wir es changelog —, das:
- die oberste
## X.Y.Z-Überschrift (optional mit -rc.N-Suffix) aus einer konfigurierbaren Datei (Default CHANGELOG.md) liest,
- prüft, ob dafür schon ein Tag existiert,
- bei Bedarf so etwas wie
relctl release create --version-scheme changelog erlaubt, ohne dass jedes Repository dieses Parsing von Hand in einem Shell-Skript pflegt (core-ng tut das aktuell in .github/workflows/tag-release.yml — ~15 Zeilen grep/git rev-parse, die bei jedem weiteren Repository mit diesem Verfahren identisch kopiert würden)?
Für: Genau die Art Wiederholung, die relctl schon für SemVer und CalVer verhindert. Ein Repository, das auf das CHANGELOG-Verfahren wechselt, bekäme dieselbe Ein-Zeilen-Integration wie die anderen beiden Schemata.
Gegen: Das CHANGELOG-Verfahren ist bewusst kein "ein Push löst automatisch etwas aus"-Mechanismus wie die anderen beiden — es lebt davon, dass der Release-PR selbst der Reviewgegenstand ist. Ob sich das sauber in relctls bestehendes Modell (ein CLI-Aufruf, der einen Release erzeugt) einfügt, oder ob es besser ein eigenständiger, kleiner Mechanismus je Repository bleibt (wie aktuell in core-ng), ist nicht entschieden — dieses Issue klärt nur, ob es sich lohnt, es zu prüfen.
Diese Abwägung wurde nicht getroffen — sie liegt bei euch. Diese Übergabe erfindet keine Antwort.
Falls ja — was ein changelog-Schema mindestens können müsste
- Datei konfigurierbar (Default
CHANGELOG.md), analog zu .relctl.yamls bestehendem Konfigurationsmuster.
- Regex für die oberste Überschrift, inklusive optionalem Suffix (core-ng nutzt
-rc.N für Release-Candidates, die separat unter einem next-artigen Kanal laufen).
- Idempotenz: ein zweiter Lauf gegen eine bereits getaggte Überschrift tut nichts (kein Fehler).
- Die eigentliche Publish-Seite bleibt unverändert Sache des aufrufenden Repositories/seiner Pipeline —
relctl liefert nur die Version und den Tag, wie bei den anderen beiden Schemata auch.
Referenzen
- core-ng:
.github/workflows/tag-release.yml, .github/workflows/publish.yml, Kopf von CHANGELOG.md (erklärt das Verfahren für Konsumenten)
- Arcon:
STD-release-procedures (Standard, org-weit)
Layer87/arcon-hub#460 (die konkrete Übergabe, die diese Frage aufgeworfen hat)
Kontext
Bei Layer87 wird gerade erhoben, wie ein drittes Release-Verfahren (CHANGELOG-gesteuert, aus
Layer87/core-ng) inLayer87/arcon-hubeingerichtet werden könnte — Details inLayer87/arcon-hub#460und im Arcon-StandardSTD-release-procedures(org-weit, aktuellpending_review).relctlkennt heute zwei Versionsschemata:feature/,fix/,major/…)YYYY.MM.DD.N, aus lokalen Git-Tags berechnetBeide leiten die Version aus etwas ab, das vor dem Release feststeht, ohne dass jemand sie explizit hinschreibt. Das CHANGELOG-gesteuerte Verfahren aus core-ng tut das Gegenteil bewusst: die Version steht in einer
## X.Y.Z — YYYY-MM-DD-Überschrift, die ein Mensch (oder ein Release-PR) selbst inCHANGELOG.mdeinträgt — der Merge dieses PRs ist die Veröffentlichung. Es ist kein technisch abgeleiteter, sondern ein kuratierter, im Review sichtbarer Wert.Die Frage, die dieses Issue stellt
Sollte
relctlein drittes Versionsschema bekommen — nennen wir eschangelog—, das:## X.Y.Z-Überschrift (optional mit-rc.N-Suffix) aus einer konfigurierbaren Datei (DefaultCHANGELOG.md) liest,relctl release create --version-scheme changelogerlaubt, ohne dass jedes Repository dieses Parsing von Hand in einem Shell-Skript pflegt (core-ng tut das aktuell in.github/workflows/tag-release.yml— ~15 Zeilengrep/git rev-parse, die bei jedem weiteren Repository mit diesem Verfahren identisch kopiert würden)?Für: Genau die Art Wiederholung, die
relctlschon für SemVer und CalVer verhindert. Ein Repository, das auf das CHANGELOG-Verfahren wechselt, bekäme dieselbe Ein-Zeilen-Integration wie die anderen beiden Schemata.Gegen: Das CHANGELOG-Verfahren ist bewusst kein "ein Push löst automatisch etwas aus"-Mechanismus wie die anderen beiden — es lebt davon, dass der Release-PR selbst der Reviewgegenstand ist. Ob sich das sauber in
relctls bestehendes Modell (ein CLI-Aufruf, der einen Release erzeugt) einfügt, oder ob es besser ein eigenständiger, kleiner Mechanismus je Repository bleibt (wie aktuell in core-ng), ist nicht entschieden — dieses Issue klärt nur, ob es sich lohnt, es zu prüfen.Diese Abwägung wurde nicht getroffen — sie liegt bei euch. Diese Übergabe erfindet keine Antwort.
Falls ja — was ein
changelog-Schema mindestens können müssteCHANGELOG.md), analog zu.relctl.yamls bestehendem Konfigurationsmuster.-rc.Nfür Release-Candidates, die separat unter einemnext-artigen Kanal laufen).relctlliefert nur die Version und den Tag, wie bei den anderen beiden Schemata auch.Referenzen
.github/workflows/tag-release.yml,.github/workflows/publish.yml, Kopf vonCHANGELOG.md(erklärt das Verfahren für Konsumenten)STD-release-procedures(Standard, org-weit)Layer87/arcon-hub#460(die konkrete Übergabe, die diese Frage aufgeworfen hat)