OpenClaw-Release-Maintainer

OpenClaw Release Maintainer

Verwenden Sie dieses Skill für den Release- und Veröffentlichungs-Workflow. Halten Sie normale Entwicklungsänderungen und GHSA-spezifische Advisory-Arbeiten außerhalb dieses Skills.

Release-Schutzmechanismen beachten

• Ändern Sie keine Versionsnummern ohne ausdrückliche Genehmigung des Operators.
• Holen Sie vor jedem npm-Publish- oder Release-Schritt die Erlaubnis ein.
• Dieses Skill sollte ausreichen, um den normalen Release-Fluss vollständig zu steuern.
• Verwenden Sie die privaten Maintainer-Release-Dokumente für Anmeldeinformationen, Wiederherstellungsschritte und Mac-Signing/Notary-Details sowie docs/reference/RELEASING.md für die öffentliche Richtlinie.
• Das openclaw-Core-Publish erfolgt manuell per workflow_dispatch. Das Erstellen oder Pushen eines Tags veröffentlicht nicht von selbst.
• Normale Release-Arbeiten erfolgen auf einem von main abgezweigten Branch, nicht direkt auf main. Verwenden Sie release/YYYY.M.D für den Branchnamen.
• Wenn der Operator nach einem Release fragt, ohne stable/full zu sagen, standardmäßig nur Beta. Fahren Sie nur dann von Beta zu Stable fort, wenn der Operator explizit nach dem vollständigen Release oder einem automatisierten Beta-and-Stable-Zug fragt.
• Vor dem Release-Branching das neueste main pullen und bestätigen, dass das aktuelle main CI grün ist. Dann von diesem Commit abzweigen, damit die normale Entwicklung auf main fortgesetzt werden kann, während die Release-Validierung läuft.
• Vor dem Release-Branching alle ungespeicherten Dateien in kohärenten Gruppen committen, pushen, pullen/rebasisieren, dann /changelog auf main ausführen und diese Changelog-Neuschreibung sofort vor der Erstellung des Release-Branches commiten/pushen/pullen.
• Während der Release-Planung sowohl src/plugins/compat/registry.ts als auch src/commands/doctor/shared/deprecation-compat.ts vor dem Branching und erneut vor der endgültigen Veröffentlichung inspizieren. Für jeden veralteten oder zur Entfernung anstehenden Kompatibilitätseintrag, dessen removeAfter-Datum am oder vor dem Veröffentlichungsdatum liegt, entweder den Kompatibilitätspfad entfernen, wo es sicher ist, und die betroffenen Tests validieren, oder aufschreiben, warum die Entfernung blockiert ist, und die ausdrückliche Genehmigung des Maintainers einholen, bevor der abgelaufene Kompatibilitätspfad ausgeliefert wird.
• Beim Entfernen veralteter Runtime-/Konfigurationskompatibilität die Arzt-Migration, -Reparatur oder -Hinweise beibehalten, die von unterstützten Upgrade-Pfaden noch benötigt werden. Die Arztseitige Kompatibilität sollte in src/commands/doctor/shared/deprecation-compat.ts verfolgt werden, bis die Maintainer bestätigen, dass die Reparatur nicht mehr benötigt wird.
• Kompatibilitätsersatztexte während der Release-Planung neu validieren. Der empfohlene Ersatz kann sich verschieben, wenn Plugin-Besitz, Externalisierung und Konfigurationsfußabdruck wechseln. Kopieren Sie daher keine veralteten Ersatzannotierungen blind in die Release-Notes.
• Beta-Tags nicht löschen oder umschreiben, nachdem das dazugehörige npm-Paket veröffentlicht wurde. Wenn ein gepushtes Beta-Tag vor der npm-Veröffentlichung fehlschlägt, ist die Version nicht verbraucht: dasselbe -beta.N behalten, den Git-Tag löschen/neu erstellen oder forciert verschieben und die Vorabversion auf den reparierten Commit setzen und Preflight erneut ausführen. Nicht zur nächsten Beta-Nummer erhöhen, bis das dazugehörige npm-Paket tatsächlich veröffentlicht ist. Wenn eine veröffentlichte Beta einen Fix benötigt, den Fix auf dem Release-Branch committen und auf die nächste -beta.N erhöhen.
• Für einen Beta-Release-Zug zuerst das schnelle lokale Preflight ausführen, die Beta auf npm beta veröffentlichen, dann das teure veröffentlichte Paket-Roster ausführen, das auf Install/Update/Docker/Parallels/NPM Telegram fokussiert ist. Wenn etwas fehlschlägt, auf dem Release-Branch beheben, commiten/pushen/pullen, Beta-Nummer erhöhen und wiederholen. Das vollständige teure Roster mindestens einmal vor der Stable/Latest-Promotion ausführen; für spätere Beta-Versuche nur Lanes erneut ausführen, deren Nachweis sich geändert hat, es sei denn, der Fix betrifft breites Release, Install/Update, Plugin, Docker, Parallels oder Live-QA-Verhalten. Nach jeder veröffentlichten Beta das aktuelle main einmal auf kritische Fixe scannen, die nach dem Release-Branch-Cut gelandet sind, und nur wichtige, risikoarme Fixe zurückportieren. Operatoren können bis zu 4 autonome Beta-Versuche autorisieren; nach 4 fehlgeschlagenen Beta-Versuchen anhalten und melden.
• /changelog vor der Version/Tag-Vorbereitung verwenden, damit der oberste Changelog-Abschnitt dedupliziert und nach Benutzerauswirkung geordnet ist.
• Keine beta-spezifischen CHANGELOG.md-Überschriften erstellen. Beta-Releases verwenden den stabilen Basisversionsabschnitt, z.B. verwendet v2026.4.20-beta.1 die ## 2026.4.20 Release-Notes.
• Wenn ein Beta- oder Stable-Release live ist, eine Discord-Ankündigung nach bestem Wissen unter Verwendung des konfigurierten geheimen Workflows machen; das Release nicht blockieren oder zurückrollen, wenn die Ankündigung fehlschlägt.
• Wenn aufgefordert, auf X anzukündigen, ~/Projects/bird/bird verwenden und dem Release-Tweet-Stil unten folgen.

Release-Kanal-Benennung konsistent halten

• stable: nur getaggte Releases, standardmäßig auf npm beta veröffentlicht; Operatoren können explizit auf npm latest abzielen oder später promovieren
• beta: Pre-Release-Tags wie vYYYY.M.D-beta.N, mit npm dist-tag beta
• -beta.N bevorzugen; keine neuen -1 oder -2 Beta-Suffixe erstellen
• dev: beweglicher Head auf main
• Bei Verwendung eines Beta-Git-Tags npm mit dem passenden Beta-Versionssuffix veröffentlichen, damit die reine Version nicht verbraucht oder blockiert wird

Versionen und Release-Dateien konsistent behandeln

• Versionsorte umfassen:
  • package.json
  • apps/android/app/build.gradle.kts
  • apps/ios/Sources/Info.plist
  • apps/ios/Tests/Info.plist
  • apps/macos/Sources/OpenClaw/Resources/Info.plist
  • docs/install/updating.md
  • Peekaboo Xcode-Projekt und Plist-Versionsfelder
• Vor der Erstellung eines Release-Tags jeden der obigen Versionsorte mit der von diesem Tag codierten Version übereinstimmen lassen.
• Für Fallback-Korrektur-Tags wie vYYYY.M.D-N bleiben die Repo-Versionsorte weiterhin bei YYYY.M.D.
• „Version überall erhöhen“ bedeutet alle Versionsorte oben außer appcast.xml.
• Release-Signing- und Notary-Anmeldeinformationen leben außerhalb des Repos in den privaten Maintainer-Dokumenten.
• Jedes stabile OpenClaw-Release liefert das npm-Paket und die macOS-App zusammen. Beta-Releases liefern normalerweise zuerst npm/Paket-Artefakte und überspringen Mac-App-Build/Sign/Notarize, es sei denn, der Operator fordert eine Mac-Beta-Validierung an.
• Den langsameren macOS-Signing/Notary-Pfad die npm-Veröffentlichung nicht blockieren lassen, sobald das npm-Preflight bestanden wurde. Mac-Validierung/Veröffentlichung parallel laufen lassen, npm aus dem erfolgreichen npm-Preflight veröffentlichen, dann mit der veröffentlichten npm-Install/Update-, Docker- und Parallels-Überprüfung beginnen, während die Mac-Artefakte fortgesetzt werden.
• Nachdem eine Beta veröffentlicht wurde, manuelle/Remote-Release-Roster überlappen, wo nützlich, aber lokale Docker-, Parallels- und QA-Lab-Arbeiten auf demselben Host vermeiden, wenn dies Systemauslastungsrauschen erzeugen würde. Selektive Wiederholungen nach Fehlern oder Korrekturen verwenden, aber sicherstellen, dass Docker, Parallels und QA-Lab jeweils mindestens einmal vor der Stable/Latest-Promotion bestanden haben.
• Mac-Packaging kann aus einer leichten Release-Branch-Variation des getaggten Commits erstellt werden, wenn das Delta nur Mac-Packaging, Signing, Workflow oder validierungsspezifische Release-Mechanismen betrifft. Wenn Mac-Packaging nur auf dem Release-Branch basierende Korrekturen benötigt, nachdem das stabile npm-Paket oder der GitHub-Tag bereits veröffentlicht wurde, keinen vYYYY.M.D-N-Korrektur-Tag nur zur Änderung der Workflow-Quelle erstellen. Die privaten Mac-Workflows für den ursprünglichen tag=vYYYY.M.D mit source_ref=release/YYYY.M.D und public_release_branch=release/YYYY.M.D auslösen; Provenienzprüfungen müssen nachweisen, dass der Source-SHA vom Tag abstammt und Validierung/Preflight dieselbe Quelle verwenden. vYYYY.M.D-N-Korrektur-Tags für Notfall-Hotfixes reservieren, die eine neue npm-Paket-/Release-Identität veröffentlichen müssen, nicht für gewöhnliche Mac-only-Packaging-Wiederherstellung.
• Der Produktions-Sparkle-Feed lebt unter https://raw.githubusercontent.com/openclaw/openclaw/main/appcast.xml, und die kanonische veröffentlichte Datei ist appcast.xml auf main im openclaw-Repo.
• Dieser gemeinsame Produktions-Sparkle-Feed ist nur für stable. Beta-Mac-Releases können Assets zum GitHub-PreRelease hochladen, aber sie dürfen die gemeinsame appcast.xml nicht ersetzen, es sei denn, es existiert ein separater Beta-Feed.
• Für Fallback-Korrektur-Tags wie vYYYY.M.D-N bleibt die Repo-Version bei YYYY.M.D, aber das Mac-Release muss eine strikt höhere numerische APP_BUILD / Sparkle-Build als das ursprüngliche Release verwenden, damit bestehende Installationen es als neuer ansehen.

Changelog-gestützte Release-Notes erstellen

• Vor Release-Branching oder Tagging den Zielabschnitt von CHANGELOG.md aus dem Commit-Verlauf umschreiben, nicht nur aus vorhandenen Notizen: Commits seit dem letzten erreichbaren Release-Tag scannen, übersehene benutzersichtbare Änderungen hinzufügen, überlappende Einträge deduplizieren und jeden Abschnitt von am interessantesten zu am wenigsten interessanten für Benutzer sortieren.
• Changelog-Einträge sollten benutzersichtig sein, keine internen Release-Prozess-Notizen.
• GitHub-Release- und PreRelease-Textkörper müssen den vollständigen passenden CHANGELOG.md-Versionsabschnitt verwenden, nicht Höhepunkte oder einen Auszug. Beim Erstellen oder Bearbeiten eines Releases von ## YYYY.M.D bis zur Zeile vor der nächsten Ebene-2-Überschrift extrahieren und diesen vollständigen Block als Release-Notes verwenden.
• Bei der Vorbereitung von Release-Notes src/plugins/compat/registry.ts und src/commands/doctor/shared/deprecation-compat.ts auf Kompatibilitätseinträge mit warningStarts oder removeAfter innerhalb von 7 Tagen nach dem Veröffentlichungsdatum scannen. Einen Hinweis „Anstehende Veraltungen“ zu den Release-Notes hinzufügen, wenn solche existieren, einschließlich des Kompatibilitätscodes, Zieldatum, Ersatz und einem Link zum docsPath des Eintrags oder zu /plugins/compatibility, wenn keine spezifischere Veraltungsseite existiert.
• Beim Schneiden eines Mac-Releases mit einem Beta-GitHub-PreRelease:
  • vYYYY.M.D-beta.N vom Release-Commit taggen
  • ein PreRelease mit dem Titel openclaw YYYY.M.D-beta.N erstellen
  • Release-Notes aus dem stabilen Basis-CHANGELOG.md-Versionsabschnitt (## YYYY.M.D) verwenden, nicht eine beta-spezifische Überschrift
  • mindestens das Zip und das dSYM-Zip anhängen, plus dmg, falls verfügbar
• Die oberen Versionseinträge in CHANGELOG.md nach Auswirkung sortiert halten:
  • ### Changes zuerst
  • ### Fixes dedupliziert mit benutzersichtigen Korrekturen zuerst

Release-Tweets schreiben

Den bestehenden Release-Post-Stil des OpenClaw-Kontos verwenden:

• Format: OpenClaw YYYY.M.D 🦞 oder 🦞 OpenClaw YYYY.M.D is live, Leerzeile, dann 3-4 Emoji-geführte Aufzählungspunkte, Leerzeile, ein kurzer Point, dann der Release-Link.
• Für Beta: OpenClaw YYYY.M.D-beta.N 🦞 oder OpenClaw YYYY.M.D beta N is live sagen; klar als Beta kennzeichnen und nicht auf Stable-Promotion schließen lassen.
• Mit benutzersichtbaren Fähigkeiten führen, dann wichtigen Integrationen, dann Zuverlässigkeits-/Sicherheits-/Installationskorrekturen. „Viele Korrekturen“ in einen lesbaren Aufzählungspunkt komprimieren.
• Den vollständigen Changelog-Abschnitt vor dem Entwurf lesen. Nicht mit Coverage, CI, Validierung oder internen Release-Mechanismen beginnen, es sei denn, das Release handelt explizit davon. Peter bevorzugt konkrete Benutzervorteile: Features, Integrationen, Workflow-Verbesserungen und praktische Zuverlässigkeitskorrekturen.
• QA-Parität, Testabdeckung, Release-Gates oder Validierungslanes in benutzersichtigen Start-Tweets nicht hervorheben. Für Release-Notes oder Maintainer-Nachweise aufbewahren, es sei denn, der Operator fordert explizit validierungsfokussierte Texte an.
• Plugin-Autor- oder Entwickler-Tools wie SDK-Helfer, Tool-Plugin-Scaffolding, Build-/Validierungs-/Init-Befehle oder interne CLI-Infrastruktur in allgemeinen benutzersichtigen Start-Tweets nicht hervorheben, es sei denn, der Operator fordert explizit entwicklerfokussierte Texte an.
• Ton: signalstark, leicht frech, selbstbewusst, nicht korporativ. Ein Witz reicht. Vermeiden Sie, auf Benutzer herabzuschauen, sie zu beleidigen oder zu versprechen, was nicht verifiziert wurde.
• Peter mag trockene, kompakte Schlagzeilen, wenn sie sich verdient anfühlen. Gutes Beispiel: Big release, tiny release notes... kidding. Den Witz kurz halten und die Feature-Aufzählungspunkte den Tweet tragen lassen; den Point nicht zu einem zweiten Absatz oder einem gezwungenen Gag machen.
• Länge: Release-Tweets sind immer Standard-Tweets unter 280 Zeichen, mit Platz für eine URL. Auf 3-4 Aufzählungspunkte kürzen und den endgültigen Text vor dem Posten zählen.
• Links/Medien: den GitHub-Release- oder Changelog-Link am Ende des ersten Release-Tweets einfügen.
• Thread-Folgebeiträge: Bei einem Thread den ersten Release-Tweet als kompakten Startbeitrag behalten, dann einen fokussierten Feature-Erklärer pro Antwort veröffentlichen. Folgebeiträge sollten nicht „NEU in VERSION“ oder die Versionsnummer wiederholen, wenn der Thread-Kontext es bereits offensichtlich macht.
• Peters bevorzugter Thread-Workflow: zuerst den generischen Start-Tweet absprechen, dann Schritt für Schritt durch die Folgebeiträge gehen. Wenn er next sagt, nur den nächsten Folgebeitrag bereitstellen oder kopieren; den vollständigen Thread nicht erneut ausgeben, es sei denn, danach gefragt.
• Jeder Folgebeitrag sollte eine Docs-URL für dieses spezifische Feature enthalten. Bevorzugen Sie eine nackte URL gegenüber Dokumentation: <URL>, es sei denn, das Label wird aus Klarheitsgründen benötigt. Folgebeiträge prägnant halten: etwa 160-220 Rohzeichen ist normalerweise die Sweet Spot; unter 280 ist die harte Grenze. Wenn eine URL einen Tweet zum Scheitern bringt, Prosa kürzen, bevor die URL weggelassen wird. Bevorzugen Sie die Erklärung von Diagnosen, Trajectory/Export, Provider-Setup, Modellbefehlen oder anderen setupschweren Features in Folgebeiträgen, anstatt den ersten Release-Tweet zu überladen.
• Hotfix/Korrektur: direkt und rechenschaftspflichtig sein. Angeben, was durchgerutscht ist, was behoben wurde, und die neue Version. Witze aus beitragsartigen Posts heraushalten.

Anzupassende Beispiele:

OpenClaw 2026.4.20-beta.1 🦞

🐳 Docker-Install/Update-Smoke
🖥️ Parallels-Upgrade-Prüfungen
🔧 Paketüberprüfung verschärft

Beta zuerst. Stable nach dem Spießrutenlauf.
<release link>

OpenClaw 2026.4.20 🦞

🚀 Schnellere Installation + Update
🐳 Docker + Parallels verifiziert
🍎 macOS signiert + notariell beglaubigt
🔧 Kanal-/Plugin-Korrekturen

Gutes langweiliges Release. Die beste Sorte.
<release link>

Packaging-Problem in 2026.4.20-beta.1.

2026.4.20-beta.2 behebt Install/Update-Verifizierung. Keine Tag-Neuschreibungen; Beta geht voran.

Upgrade mit dem Beta-Kanal.
<release link>

Veröffentlichungszeit-Validierung ausführen

Vor Tagging oder Veröffentlichung ausführen:

pnpm check:architecture
pnpm build
pnpm ui:build
pnpm qa:otel:smoke
pnpm release:check
pnpm test:install:smoke

• pnpm qa:otel:smoke verwenden, wenn die Release-Validierung Telemetrieabdeckung benötigt. Es startet einen lokalen OTLP/HTTP-Trace-Empfänger, führt otel-trace-smoke von QA-lab aus und überprüft Spannnamen sowie Inhalts-/Identifikator-Schwärzung ohne externen Opik oder …

… [für die Übersetzung abgeschnitten]