OpenClaw リリースメンテナー

OpenClaw リリースメンテナー は何をしますか？

リリースおよび公開時のワークフローにはこのスキルを使用します。通常の開発変更や GHSA 固有の勧告作業はこのスキルの範囲外です。

リリースガードレールを尊重する

• 明示的なオペレーターの承認なしにバージョン番号を変更しないでください。
• npm 公開またはリリースステップの前に許可を求めてください。
• このスキルは、通常のリリースフローをエンドツーエンドで駆動するのに十分であるべきです。
• 資格情報、復旧手順、Mac の署名/公証の詳細についてはプライベートメンテナーリリースドキュメントを参照し、公開ポリシーについては docs/reference/RELEASING.md を使用してください。
• コア openclaw の公開は手動の workflow_dispatch です。タグを作成またはプッシュしても、それ自体で公開されることはありません。
• 通常のリリース作業は main から切り出されたブランチで行われ、main 上で直接行われることはありません。ブランチ名には release/YYYY.M.D を使用してください。
• オペレーターが安定版/フルリリースと言わずにリリースを依頼した場合は、デフォルトでベータのみとします。オペレーターが明示的にフルリリースまたは自動化されたベータ・アンド・ステーブルトレインを要求した場合にのみ、ベータから安定版に進みます。
• リリースブランチを作成する前に、最新の main をプルし、現在の main の CI がグリーンであることを確認してください。その後、そのコミットからブランチを作成し、リリース検証が実行されている間も main での通常の開発を続行できるようにします。
• リリースブランチを作成する前に、ダーティファイルを一貫性のあるグループにコミットし、プッシュ、プル/リベースしてから、main で /changelog を実行し、そのチェンジログの書き換えをコミット/プッシュ/プルしてから、リリースブランチを作成してください。
• リリース計画中に、src/plugins/compat/registry.ts と src/commands/doctor/shared/deprecation-compat.ts の両方を、ブランチ作成前と最終公開前の再度確認してください。removeAfter 日付がリリース日以前の非推奨または削除予定の互換性レコードについては、安全な場所で互換性パスを削除して影響を受けるテストを検証するか、削除がブロックされている理由を文書化し、期限切れの互換性パスを出荷する前に明示的なメンテナーの承認を得てください。
• 非推奨のランタイム/設定互換性を削除する場合は、サポートされているアップグレードパスで引き続き必要となる doctor のマイグレーション、修復、またはヒントを保持してください。Doctor 側の互換性は、メンテナーが修復が不要になったことを確認するまで、src/commands/doctor/shared/deprecation-compat.ts で追跡し続ける必要があります。
• リリース計画中に互換性の代替テキストを再検証してください。プラグインの所有権、外部化、および設定フットプリントが移動するにつれて、推奨される代替が変わる可能性があるため、古い代替アノテーションを盲目的にリリースノートにコピーしないでください。
• 一致する npm パッケージが公開された後は、ベータタグを削除または書き換えないでください。プッシュされたベータタグが npm 公開前に失敗した場合、そのバージョンは使用されていません。同じ -beta.N を維持し、git タグとプレリリースを修正コミットに削除/再作成または強制移動し、プリフライトを再実行してください。一致する npm パッケージが実際に公開されるまで、次のベータ番号にインクリメントしないでください。公開されたベータに修正が必要な場合は、リリースブランチに修正をコミットし、次の -beta.N にインクリメントしてください。
• ベータリリーストレインの場合、最初に高速なローカルプリフライトを実行し、npm beta に公開してから、インストール/アップデート/Docker/Parallels/NPM Telegram に焦点を当てた高コストな公開パッケージロスターを実行してください。何かが失敗した場合は、リリースブランチで修正し、コミット/プッシュ/プルし、ベータ番号をインクリメントして繰り返します。安定版/最新版プロモーションの前に、少なくとも 1 回は完全な高コストロスターを実行してください。後のベータ試行では、修正が広範なリリース、インストール/アップデート、プラグイン、Docker、Parallels、またはライブ QA 動作に影響を与えない限り、証拠が変更されたレーンのみを再実行してください。各ベータが公開された後、現在の main を 1 回スキャンして、リリースブランチカット後に取り込まれた重要な修正を確認し、重要で低リスクの修正のみをバックポートしてください。オペレーターは最大 4 回の自律ベータ試行を承認する場合があります。4 回のベータ試行が失敗した後は停止して報告してください。
• バージョン/タグ準備の前に /changelog を使用して、トップのチェンジログセクションが重複排除され、ユーザーへの影響で並べ替えられるようにしてください。
• ベータ固有の CHANGELOG.md 見出しを作成しないでください。ベータリリースは安定版ベースバージョンセクションを使用します。たとえば、v2026.4.20-beta.1 は ## 2026.4.20 リリースノートを使用します。
• ベータまたは安定版リリースが公開されたら、設定されたシークレットワークフローを使用して Discord にベストエフォートでアナウンスしてください。アナウンスが失敗しても、リリースをブロックまたはロールバックしないでください。
• X でアナウンスするように求められた場合は、~/Projects/bird/bird を使用し、以下のリリースツイートスタイルに従ってください。

リリースチャネルの命名を統一する

• stable: タグ付きリリースのみ。デフォルトで npm beta に公開されます。オペレーターは明示的に npm latest をターゲットにするか、後でプロモートできます。
• beta: vYYYY.M.D-beta.N のようなプレリリースタグ。npm ディストリビューションタグは beta です。
• -beta.N を優先してください。新しい -1 または -2 のベータサフィックスを作成しないでください。
• dev: main 上の移動ヘッド
• ベータ Git タグを使用する場合は、プレーンバージョンが使用またはブロックされないように、一致するベータバージョンサフィックスを付けて npm を公開してください。

バージョンとリリースファイルを一貫して扱う

• バージョンの場所は次のとおりです。
  • 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 プロジェクトおよび plist バージョンフィールド
• リリースタグを作成する前に、上記のすべてのバージョン場所を、そのタグでエンコードされたバージョンと一致させてください。
• vYYYY.M.D-N のようなフォールバック修正タグの場合、リポジトリのバージョン場所は YYYY.M.D のままです。
• 「すべての場所でバージョンを上げる」とは、appcast.xml を除く上記のすべてのバージョン場所を意味します。
• リリースの署名と公証の資格情報は、リポジトリ外のプライベートメンテナードキュメントに保存されます。
• すべての安定版 OpenClaw リリースは、npm パッケージと macOS アプリを一緒に出荷します。ベータリリースは通常、npm/パッケージアーティファクトを最初に出荷し、mac アプリのビルド/署名/公証は、オペレーターが mac ベータ検証を要求しない限りスキップします。
• npm プリフライトが完了したら、macOS の署名/公証パスが遅くても npm 公開をブロックしないでください。mac 検証/公開を並行して実行し、成功した npm プリフライトから npm を公開してから、mac アーティファクトの処理を続行しながら、公開された npm インストール/アップデート、Docker、および Parallels の検証を開始してください。
• ベータが公開された後は、リモート/手動のリリースロスターを有用な場所で重複させてください。ただし、同じホストにローカルの Docker、Parallels、QA-Lab ワークを積み重ねてシステム負荷ノイズを発生させないようにしてください。失敗または修正後は選択的に再実行しますが、安定版/最新版プロモーションの前に Docker、Parallels、QA-Lab がそれぞれ少なくとも 1 回合格したという証拠を維持してください。
• Mac パッケージングは、デルタが mac パッケージング、署名、ワークフロー、または検証専用のリリースメカニズムである場合、タグ付きコミットからわずかにリリースブランチを変更してビルドされる場合があります。安定版の npm パッケージまたは GitHub タグが既に公開された後に、mac パッケージングにリリースブランチのみの修正が必要な場合、ワークフローソースを変更するためだけに vYYYY.M.D-N 修正タグを作成しないでください。元の tag=vYYYY.M.D に対して、source_ref=release/YYYY.M.D および public_release_branch=release/YYYY.M.D を指定してプライベート mac ワークフローをディスパッチします。証明チェックは、ソース SHA がタグから派生し、検証/プリフライトが同じソースを使用することを証明する必要があります。vYYYY.M.D-N 修正タグは、新しい npm パッケージ/リリース ID を公開する必要がある緊急ホットフィックスのために予約してください。通常の mac 専用パッケージングリカバリには使用しないでください。
• プロダクション Sparkle フィードは https://raw.githubusercontent.com/openclaw/openclaw/main/appcast.xml にあり、正規の公開ファイルは openclaw リポジトリの main 上の appcast.xml です。
• その共有プロダクション Sparkle フィードは安定版のみです。ベータ mac リリースは GitHub プレリリースにアセットをアップロードしても構いませんが、別のベータフィードが存在しない限り、共有 appcast.xml を置き換えてはなりません。
• vYYYY.M.D-N のようなフォールバック修正タグの場合、リポジトリのバージョンは YYYY.M.D のままですが、mac リリースは元のリリースよりも厳密に高い数値の APP_BUILD/Sparkle ビルドを使用する必要があります。これにより、既存のインストールが新しいバージョンとして認識されるようになります。

チェンジログに基づくリリースノートを作成する

• リリースブランチまたはタグを作成する前に、ターゲットの CHANGELOG.md セクションをコミット履歴から書き換えてください。既存のノートからだけではありません。最後の到達可能なリリースタグ以降のコミットをスキャンし、見逃したユーザー向けの変更を追加し、重複するエントリを排除し、各セクションをユーザーにとって最も興味深いものから最も興味のないものへと並べ替えてください。
• チェンジログエントリは、ユーザー向けである必要があり、内部のリリースプロセスに関するメモであってはなりません。
• GitHub リリースおよびプレリリースの本文は、完全な一致する CHANGELOG.md バージョンセクションを使用する必要があります。ハイライトや抜粋ではありません。リリースを作成または編集するときは、## YYYY.M.D から次のレベル 2 見出しの前の行までを抽出し、その完全なブロックをリリースノートとして使用してください。
• リリースノートを準備するときは、src/plugins/compat/registry.ts と src/commands/doctor/shared/deprecation-compat.ts をスキャンして、warningStarts または removeAfter がリリース日から 7 日以内にある互換性レコードを探してください。存在する場合は、リリースノートに "Upcoming deprecations" ノートを追加し、互換性コード、対象日、代替、およびより具体的な非推奨ページがない場合のレコードの docsPath または /plugins/compatibility へのリンクを含めてください。
• ベータ GitHub プレリリースで mac リリースを作成する場合:
  • リリースコミットから vYYYY.M.D-beta.N タグを作成する
  • openclaw YYYY.M.D-beta.N というタイトルのプレリリースを作成する
  • 安定版ベース CHANGELOG.md バージョンセクション（## YYYY.M.D）のリリースノートを使用する。ベータ固有の見出しは使用しない
  • 少なくとも zip と dSYM zip、利用可能な場合は dmg を添付する
• CHANGELOG.md のトップバージョンエントリを影響度順に並べ替えてください。
  • ### Changes を最初に
  • ### Fixes はユーザー向けの修正を最初に重複排除

リリースツイートを作成する

OpenClaw アカウントの既存のリリース投稿スタイルを使用します。

• 形式: OpenClaw YYYY.M.D 🦞 または 🦞 OpenClaw YYYY.M.D is live、空行、次に絵文字付きの箇条書き 3～4 個、空行、1 つの短い決め台詞、次にリリースリンク。
• ベータの場合: OpenClaw YYYY.M.D-beta.N 🦞 または OpenClaw YYYY.M.D beta N is live とし、明確にベータであることを示し、安定版へのプロモーションを暗示しないようにしてください。
• まずユーザーから見える機能、次に重要な統合、最後に信頼性/セキュリティ/インストールの修正という順序で記載してください。「多数の修正」は 1 つの読みやすい箇条書きにまとめてください。
• ドラフトを作成する前に、チェンジログセクション全体をお読みください。リリースが明示的にそれらについてのものでない限り、カバレッジ、CI、検証、または内部リリースメカニズムを先頭に持ってこないでください。Peter は具体的なユーザーのメリットを好みます。機能、統合、ワークフローの改善、実用的な信頼性修正です。
• ユーザー向けのローンチツイートで、QA パリティ、テストカバレッジ、リリースゲート、または検証レーンを特徴として取り上げないでください。これらはリリースノートまたはメンテナー向けの証拠として残してください。オペレーターが明示的に検証に焦点を当てたコピーを要求した場合を除きます。
• 一般的なユーザー向けのローンチツイートで、SDK ヘルパー、ツールプラグインのスキャフォールディング、ビルド/検証/初期化コマンド、または内部 CLI 配管などのプラグイン作成者や開発者ツールを特徴として取り上げないでください。オペレーターが明示的に開発者向けのコピーを要求した場合を除きます。
• トーン: 情報量が多く、やや生意気で、自信に満ちており、企業的ではありません。冗談は 1 つで十分です。ユーザーを貶めたり、侮辱したり、検証されていないことを約束したりしないでください。
• Peter は、価値があると感じた場合の、ドライでコンパクトなキャッチフレーズを好みます。良い例: Big release, tiny release notes... kidding. 冗談は短く抑え、機能の箇条書きにツイートを運ばせてください。決め台詞を 2 番目の段落や無理のあるビットにしないでください。
• 長さ: リリースツイートは常に 280 文字未満の標準ツイートで、1 つの URL の余地を残してください。3～4 個の箇条書きにトリミングし、投稿する前に最終的なテキストをカウントしてください。
• リンク/メディア: 最初のリリースツイートの最後に GitHub リリースまたはチェンジログへのリンクを含めてください。
• スレッドフォローアップ: スレッドにする場合は、最初のリリースツイートをコンパクトなローンチ投稿として維持し、返信ごとに 1 つの焦点を絞った機能説明を公開してください。フォローアップの返信では、スレッドのコンテキストがすでに明らかな場合、"new in VERSION" やバージョン番号を繰り返さないでください。
• Peter の好むスレッドワークフロー: 最初に汎用のローンチツイートに同意し、次にフォローアップツイートを 1 つずつ進めます。彼が next と言った場合、次のフォローアップのみを提供またはコピーしてください。尋ねられない限り、スレッド全体を再度ダンプしないでください。
• すべてのフォローアップツイートには、その特定の機能のドキュメント URL を含めてください。ラベルが明確さのために必要な場合を除き、Docs: <url> よりもベア URL を優先してください。フォローアップは簡潔にしてください。通常、約 160～220 の生の文字が最適です。280 未満がハードリミットです。URL によってツイートが失敗する場合は、URL を削除する前に散文をトリミングしてください。 最初のリリースツイートに過負荷をかける代わりに、診断、トラジェクトリ/エクスポート、プロバイダーセットアップ、モデルコマンド、またはその他のセットアップの多い機能をフォローアップで説明することを好みます。
• ホットフィックス/修正: 直接的かつ責任を持って対応してください。何がすり抜けたか、何が修正されたか、新しいバージョンは何かを述べてください。インシデント形式の投稿には冗談を入れないでください。

適応する例:

OpenClaw 2026.4.20-beta.1 🦞

🐳 Docker install/update smoke
🖥️ Parallels upgrade checks
🔧 Package verification tightened

Beta first. Stable after the gauntlet.
<release link>

OpenClaw 2026.4.20 🦞

🚀 Faster install + update
🐳 Docker + Parallels verified
🍎 macOS signed + notarized
🔧 Channel/plugin fixes

Good boring release. Best kind.
<release link>

Packaging issue in 2026.4.20-beta.1.

2026.4.20-beta.2 fixes install/update verification. No tag rewrites; beta moves
forward.

Upgrade with the beta channel.
<release link>

公開時の検証を実行する

タグ付けまたは公開前に、以下を実行してください。

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

• リリース検証にテレメトリーカバレッジが必要な場合は、pnpm qa:otel:smoke を使用してください。これはローカルの OTLP/HTTP トレースレシーバーを起動し、QA-lab の otel-trace-smoke を実行し、外部の Opik または…

...（翻訳のために切り詰められました）