av/remotion-bits

Remotion Bits Release

Verwende diesen Skill, wenn du eine neue remotion-bits Version aus diesem Repository vorbereitest und veröffentlichst.

Was dieser Skill tut

Dieser Skill führt den vollständigen Release-Workflow durch:

1. Erhöhe die Version in ./package.json. Standardmäßig wird ein Patch-Bump durchgeführt, es sei denn, der Benutzer fordert explizit Minor, Major oder eine bestimmte Version an.
2. Aktualisiere CHANGELOG.md mit prägnanten Release-Notizen für die neue Version.
3. Führe npm run registry:build aus.
4. Committe die Release-Änderungen mit chore: vX.Y.Z.
5. Pushe den Release-Commit auf master.
6. Recherchiere bemerkenswerte Änderungen seit dem vorherigen Release anhand der Git-Historie und zusammengeführter PRs.
7. Öffne das vorausgefüllte GitHub-Release-Formular mit dem systemeigenen Browser, nicht dem internen Browser.
8. Nachdem das GitHub-Release veröffentlicht wurde, stelle die Dokumentation mit ./scripts/deploy-docs.sh bereit.
9. Veröffentliche das Paket auf npm mit npm publish.

Voraussetzungen

• Arbeite vom Repository-Stammverzeichnis aus.
• Starte den Docs-Entwicklungsserver nicht.
• Gehe davon aus, dass für die Veröffentlichung gültige GitHub-, Cloudflare- und npm-Anmeldeinformationen bereits in der Umgebung konfiguriert sind.
• Wenn der Arbeitsbaum nicht zusammenhängende Benutzeränderungen enthält, mache diese nicht rückgängig. Arbeite entweder um sie herum oder stoppe und frage nach, bevor du sie berührst, falls sie die Release-Dateien betreffen.

Release-Workflow

1. Bestimme die Zielversion

• Lies die aktuelle Version aus ./package.json.
• Wenn der Benutzer eine bestimmte Version angegeben hat, verwende sie.
• Wenn der Benutzer einen Bump-Typ angegeben hat, wende ihn an.
• Andernfalls führe einen Patch-Bump durch.
• Der Git-Tag und der Release-Titel müssen vX.Y.Z lauten.

2. Bereite Release-Notizen vor

• Überprüfe die Commits seit dem letzten veröffentlichten Tag.
• Überprüfe zusammengeführte PRs, wenn sie helfen, die Änderungen zusammenzufassen.
• Aktualisiere CHANGELOG.md, indem du den neuen Versionsabschnitt oben einfügst.
• Halte die Einträge prägnant und benutzerorientiert.
• Verwende dieses Format:

### vX.Y.Z

- Feature: Kurze Beschreibung des neuen Features
- Fix: Kurze Beschreibung des Bugfixes
- Verbesserung: Kurze Beschreibung der Optimierung
- Docs: Kurze Beschreibung der Dokumentationsänderung

3. Version erhöhen und Registry bauen

• Aktualisiere ./package.json auf die neue Version.
• Führe aus:

npm run registry:build

• Wenn der Build fehlschlägt, stoppe und behebe das zugrunde liegende Problem, bevor du fortfährst.

4. Den Release committen und pushen

• Überprüfe das Release-Diff.
• Committe das vorbereitete Release mit:

git commit -am "chore: vX.Y.Z"

• Pushe den Commit auf master.
• Wenn das Repository hinter dem Remote zurückliegt oder der Push fehlschlägt, löse diesen Zustand auf, bevor du fortfährst.

5. Das GitHub-Release entwerfen

• Baue Release-Notizen aus der Changelog-Zusammenfassung und den aktuellen Commits.
• Öffne diese URL mit xdg-open oder einem anderen systemeigenen Befehl, niemals mit dem internen Browser:

https://github.com/everlier/remotion-bits/releases/new?tag=vX.Y.Z&target=master&title=vX.Y.Z&body=...

• Fülle das Formular voraus mit:

  • tag: vX.Y.Z
  • target: master
  • title: vX.Y.Z
  • prerelease: false

• Der Release-Body sollte dieser Struktur folgen:

## Was gibt's Neues

- Ein kurzer Satz pro bemerkenswertem neuen Feature.
- Ein kurzer Satz pro bemerkenswertem Bugfix.
- Ein kurzer Satz pro bemerkenswerter Verbesserung.

**Vollständiges Changelog**: https://github.com/everlier/remotion-bits/compare/vX.Y.(Z-1)...vX.Y.Z

• Halte inne und warte, bis der Benutzer das GitHub-Release veröffentlicht, wenn eine Browser-Bestätigung erforderlich ist.

6. Dokumentation bereitstellen

• Nachdem das GitHub-Release veröffentlicht wurde, führe aus:

./scripts/deploy-docs.sh

7. Auf npm veröffentlichen

• Bestätige, dass die npm-Authentifizierung verfügbar ist.
• Veröffentliche vom Repository-Stammverzeichnis aus:

npm publish

Entscheidungsregeln

• Standardmäßig werden Patch-Releases erstellt, es sei denn, der Benutzer sagt etwas anderes.
• Wenn Release-Notizen unklar sind, leite sie aus der Commit-Historie ab, bevor du den Benutzer fragst.
• Wenn ein Befehl Release-Artefakte verändert, behalte diese generierten Änderungen im Release-Commit.
• Wenn der Publishing-Prozess einen manuellen Browser-Schritt erfordert, stoppe an der Grenze, teile dem Benutzer genau mit, worauf gewartet wird, und fahre nach der Bestätigung fort.
• Wenn Anmeldeinformationen für GitHub, Cloudflare oder npm fehlen, stoppe und melde die fehlende Voraussetzung, anstatt blind zu wiederholen.

Checkliste für den Abschluss

• package.json hat die Zielversion.
• CHANGELOG.md hat einen neuen obersten Abschnitt für diese Version.
• npm run registry:build wurde erfolgreich abgeschlossen.
• Release-Commit chore: vX.Y.Z existiert und wurde auf master gepusht.
• Das GitHub-Release-Formular wurde mit den korrekten vorausgefüllten Werten geöffnet.
• Die Dokumentation wurde bereitgestellt.
• npm publish wurde erfolgreich abgeschlossen.