Zum Inhalt springen
SupaCloud Docs
Farbschema wählenSprache wählen

Ein Release veröffentlichen

Dies ist die Standard-Arbeitsanweisung (SOP) für das Veröffentlichen eines SupaCloud-Releases. SupaCloud folgt Semantic Versioning und dem Keep a Changelog-Format. Die CHANGELOG.md im Repository-Root ist die einzige Quelle der Wahrheit für den öffentlichen, menschenlesbaren Changelog auf der /changelog-Seite der Marketing-Website (en + de) — sie wird beim Build in die Seite synchronisiert (ADR 0045).

Wann ein Changelog-Eintrag nötig ist

Abschnitt betitelt „Wann ein Changelog-Eintrag nötig ist“

Füge einen Eintrag hinzu, wann immer eine Änderung für Nutzer sichtbar ist: ein neues Feature, eine Verhaltensänderung, ein Fix, den Nutzer bemerken würden, oder eine sicherheitsrelevante Änderung. Interne Refactorings, reine Test- oder CI-Änderungen brauchen keinen Eintrag.

Der changelog-gate-CI-Workflow erzwingt das: Ein Pull Request, der web/, marketing/src/ oder docs/{user,admin}/ berührt, muss auch die CHANGELOG.md ändern.

Schritte

Abschnitt betitelt „Schritte“

  1. Trage deine Änderung unter ## [Unreleased] ein (oder im Abschnitt der anstehenden Version) in der CHANGELOG.md, in der richtigen Kategorie — Added, Changed, Deprecated, Removed, Fixed oder Security. Schreibe sie für Nutzer, nicht für das Commit-Log.

  2. Synchronisiere die Marketing-Homepage neu. Die /changelog-Seite rendert ein generiertes Modul, das aus der CHANGELOG.md synchronisiert und über einen committeten Drift-Lock fingerprinted wird:

    Terminal window
    cd marketing
    npm run sync:changelog        # Modul neu generieren + changelog.lock auffrischen
    npm run changelog:check        # bestätigen, dass der Drift-Hash passt (CI führt das aus)

    Committe die aufgefrischte marketing/src/lib/generated/changelog.lock (das vollständige generierte Modul ist gitignored — der Lock ist der Drift-Vertrag).

  3. Beim Release die Version erhöhen. Verschiebe ## [Unreleased] zu ## [X.Y.Z] - YYYY-MM-DD (lasse ein leeres ## [Unreleased] darüber für den nächsten Zyklus) und aktualisiere die Compare-Links am Dateiende. Wähle den Bump nach SemVer: breaking → MAJOR, additiv → MINOR, nur Fixes → PATCH. Führe danach die Synchronisierung aus Schritt 2 erneut aus, damit der Lock den datierten Abschnitt widerspiegelt.

  4. Lokal verifizieren vor dem Taggen:

    Terminal window
    cd marketing && npm run check && npm run build
    npx --yes markdownlint-cli2 --config .markdownlint.jsonc CHANGELOG.md

  5. Release-PR öffnen mit dem Versions-Bump und der Lock-Änderung. CI führt changelog-gate aus (Abschnitt vorhanden, Drift-Check, Markdownlint) plus die üblichen build-push-Gates.

  6. Nach dem Merge taggen. Sobald der PR auf main ist:

    Terminal window
    git tag -a vX.Y.Z -m "vX.Y.Z"
    git push origin vX.Y.Z

    Die build-push-Pipeline baut und signiert die Server-/Web-/Marketing-Images für diesen Commit; das Marketing-Image bäckt die frisch synchronisierte /changelog-Seite ein.

Siehe auch

Abschnitt betitelt „Siehe auch“