Team Intern

Release-Workflow

Interner Leitfaden für Releases, Hotfixes und Legacy-Patches im Shield Monorepo. Beschreibt den vollständigen Ablauf von Changeset-Anlage bis zum npm-Publish inklusive Git-Tagging.

Release-Workflow

Diese Seite nutzt ein eigenes Datums-System, da @changesets/cli von sich aus keine Daten in Changelog-Headings schreibt.

Schritt 1 — Changeset anlegen

Während der Entwicklung für jede relevante Änderung ein Changeset anlegen. Das Changeset beschreibt welche Pakete betroffen sind und ob es sich um ein patch, minor oder major handelt.

pnpm changeset

Es entsteht eine Datei in .changeset/. Diese wird zusammen mit dem Feature-Commit eingecheckt.

Schritt 2 — Versionen bumpen

Wenn alle Änderungen bereit für einen Release sind, Versionen bumpen. Dieser Befehl führt intern changeset version aus (bumpt package.json, schreibt CHANGELOG-Headings) und anschließend scripts/add-changelog-dates.mjs (ergänzt das korrekte Datum je Version).

pnpm version:packages

Das Datums-Script ermittelt das Datum per git log aus dem Commit, der das jeweilige Versions-Heading erstmals eingeführt hat — bestehende Releases behalten so ihr historisch korrektes Datum:

## 0.2.0              →   ## 0.2.0 — 20.02.2026
## 0.1.0              →   ## 0.1.0 — 19.02.2026

Die resultierenden Änderungen committen und pushen.

Schritt 3 — Publizieren

Pakete auf npm publizieren. changeset publish baut intern alle Pakete und erstellt danach automatisch Git-Tags im Format @scope/package@version für jeden publizierten Release.

pnpm release

Anschließend die Tags noch auf den Remote pushen:

git push --follow-tags

Zusammenfassung

pnpm changeset          # Changeset beschreiben (während Entwicklung)
pnpm version:packages   # Versionen bumpen + Dates setzen
git add . && git commit -m "chore: release"
git push
pnpm release            # Publish auf npm + Git-Tags erstellen
git push --follow-tags  # Tags auf Remote pushen

Release-Branch in main mergen

Nach dem Publish wird der Release-Branch per Fast-Forward in main gemergt. Das funktioniert konfliktfrei, solange der Branch direkt auf dem letzten main-Commit aufbaut — also keine parallelen Commits auf main entstanden sind.

git checkout main
git merge --ff-only release/your-branch
git push

--ff-only stellt sicher, dass kein ungewollter Merge-Commit entsteht. Falls main zwischenzeitlich weitergelaufen ist, schlägt der Befehl fehl — dann zuerst rebasen:

git checkout release/your-branch
git rebase main
# dann nochmal:
git checkout main
git merge --ff-only release/your-branch
git push

Hotfix-Workflow

Ein Hotfix ist ein dringender Patch-Release direkt auf main, ohne einen laufenden Feature-Branch abwarten zu müssen.

Schritt 1 — Hotfix-Branch von main

git checkout main
git pull
git checkout -b hotfix/kurze-beschreibung

Schritt 2 — Fix implementieren & Changeset anlegen

Den Fix committen, dann ein Changeset vom Typ patch anlegen:

pnpm changeset
# → patch auswählen, betroffene(s) Paket(e) markieren

Schritt 3 — Version bumpen & publizieren

pnpm version:packages           # patch-Version bumpen + Datum setzen
git add . && git commit -m "chore: hotfix release"
git push -u origin hotfix/kurze-beschreibung
pnpm release                    # Publish auf npm + Git-Tags
git push --follow-tags

Schritt 4 — Zurück in main mergen

git checkout main
git merge --ff-only hotfix/kurze-beschreibung
git push

Falls parallel ein Feature-Branch offen ist, diesen danach auf das neue main rebasen (git rebase main), damit er den Hotfix-Commit enthält.

Zusammenfassung Hotfix

git checkout main && git pull
git checkout -b hotfix/kurze-beschreibung
# ... fix implementieren & committen ...
pnpm changeset                  # patch
pnpm version:packages
git add . && git commit -m "chore: hotfix release"
git push -u origin hotfix/kurze-beschreibung
pnpm release
git push --follow-tags
git checkout main
git merge --ff-only hotfix/kurze-beschreibung
git push

Alte Version hotfixen (Legacy-Patch)

Wenn main bereits auf 1.3 ist, aber ein Nutzer noch 1.1 einsetzt und dort ein kritischer Bug gefixt werden muss, darf der Fix nicht einfach von main abgezweigt werden — das würde den 1.3-Stand mitziehen.

Stattdessen wird ein Support-Branch direkt vom alten Git-Tag erstellt:

Schritt 1 — Support-Branch vom alten Tag

# Den Tag des alten Release finden
git tag --sort=-version:refname

# Support-Branch ab dem 1.1.x-Tag erstellen
git checkout -b support/1.1.x @shield/webcomponents@1.1.0

Dieser Branch startet exakt beim Stand von 1.1.0 — unabhängig davon was auf main passiert ist.

Schritt 2 — Fix implementieren & Changeset anlegen

Da der Branch direkt vom Tag @shield/webcomponents@1.1.0 erzeugt wurde, steht package.json bereits auf 1.1.0. Einfach den Fix committen und ein patch-Changeset anlegen:

pnpm changeset
# → patch auswählen → ergibt 1.1.1

Schritt 3 — Version bumpen & publizieren

pnpm version:packages
git add . && git commit -m "chore: legacy patch 1.1.1"
git push -u origin support/1.1.x
pnpm release
git push --follow-tags

Schritt 4 — Fix nach main portieren (optional)

Wenn der Bug auch in der aktuellen Version existiert, den Fix-Commit per Cherry-Pick auf main übertragen — aber ohne den Versions-Bump-Commit:

git log support/1.1.x --oneline
# den Hash des reinen Fix-Commits (nicht des chore: release-Commits) kopieren

git checkout main
git cherry-pick <fix-commit-hash>
git push

Den Support-Branch kann man danach stehen lassen — er dient als Basis für weitere 1.1.x-Patches falls nötig.

Zusammenfassung Legacy-Patch

git checkout -b support/1.1.x @shield/webcomponents@1.1.0
# ... fix implementieren & committen ...
pnpm changeset                  # patch → 1.1.1
pnpm version:packages
git add . && git commit -m "chore: legacy patch 1.1.1"
git push -u origin support/1.1.x
pnpm release
git push --follow-tags
# optional: fix nach main cherry-picken
git checkout main && git cherry-pick <fix-commit-hash> && git push