release-stable

安定版をリリースする

安定版は最も多くの人がインストールするバージョンであり、公開後に変更されることはありません。バージョンタグはプッシュ後に移動したり削除したりすることはなく、リリースノートはすぐに公開され、インストール済みのビルドは自動的に更新されます。誤りがあった場合は、このバージョンを変更するのではなく、次のバージョンで修正します。そのため、作業の大半は、マシンの外に何かを出す前に行う確認です。

プロジェクトの安定版リリース手順を確認する

まず、プロジェクトが安定版リリースについて説明している場所を探します。

• バージョンタグによって実行されるワークフロー（例： .github/workflows/stable.yml）。通常、ヘッダーコメントに手順、タグのパターン、ビルド対象のプラットフォームが記載されています。
• リリース記述ファイルの README（例：releases/README.md）と、そこから参照される設計ページ。
• バージョンを決めるリリース作成手順（releases/WRITING.md）。
• 現在も手動で公開しているプラットフォームがある場合は、そのリリース手順書。リリース作業を CI に移行中のプロジェクトでは、一部のプラットフォームをまずローカルコマンドで公開することがあり、そのコマンドがリリースノートの作成やタグの作成まで行う場合があります。

これらによって、タグのパターン、リリースノートの保存場所と命名方法、CI がビルドするプラットフォーム、手動公開と CI ビルドの順序が決まります。該当するものがなければ、作業を中止して確認してください。安定版リリースの作成方法を独自に決めてはいけません。

何かを書く前に確認する

1. リリースするのは現在のツリーです。 タグも含めて取得し、メインブランチにいて、リモートと同期しており、作業ツリーがクリーンであることを確認します。作業中にもメインブランチは更新されるため、タグを作成する直前にもう一度確認してください。CI はタグ付けされたコミットに含まれるワークフローファイルを実行します。そのコミットより後に追加されたワークフローは実行されません。
2. タグ付けするコミットでメインブランチの CI が成功していることを確認します。 そのコミットの CI 実行結果を確認してください。ジョブに失敗があれば、作業を中止し、失敗した各ジョブと最初の実際のエラーを挙げて、先にメインブランチを修正するか確認してください。安定版リリースは後から置き換えられないため、修正を推奨します。ジョブがまだ実行中なら、そのジョブを示して、完了を待つか確認してください。
3. そのバージョンが未使用であることを確認します。 同じ名前のタグがローカルにもリモートにも存在せず（git ls-remote --tags origin v<version>）、同じ名前のリリースも存在しないことを確認します（gh release view v<version> が失敗すること）。プッシュされていないローカルタグがある場合は、その旨を一言伝えてください。以前の手動公開時に残った可能性があり、リリース対象のコミットを指している必要があります。
4. リリースする変更があることを確認します。 git log --no-merges <last stable tag or commit>..HEAD の結果が空でないことを確認してください。最後の安定版コミットは、ローカルタグではなく、公開手順に記載された場所から確認します。
5. 公開に必要な設定が済んでいることを確認します。 ワークフローの環境と、そこで指定されているシークレットが存在することを確認します（gh api repos/<owner>/<repo>/environments と、その環境のシークレット一覧）。これらが存在する前にタグをプッシュすると、その実行は失敗し、タグを取り消すことはできません。

リリースノートを作成する

安定版チャンネル用に write-release-notes を実行します。プロジェクトのルールに従ってバージョンを選び、手順に記載された記述ファイル（通常は releases/<version>.toml）を作成します。これらのルールに加えて、次の点を守ってください。

• そのバージョンのすべてのプラットフォームに対して、記述ファイルを1つ作成します。 手動で公開するプラットフォームと CI でビルドするプラットフォームには、同じリリースノートが掲載されるため、一度だけ記述します。
• 各プラットフォームについて、今回のリリースに含まれる内容だけを記載します。 機能について説明する前に、リリース対象のプラットフォームで利用できることを確認してください。通常、cfg(windows) やプラットフォームモジュールの欠落が判断の手がかりになります。特定のプラットフォームだけの変更は、そのプラットフォームの見出しの下に記載します。
• コミットメッセージの全文を確認します。1行の要約だけでは不十分です。 git log --no-merges --format='%h %s%n%b' <last stable>..HEAD を実行し、メッセージだけでは不明な点については、その変更の差分も確認してください。
• 検証します。 正しく解析でき、必須項目がすべて記入されていて空欄がなく、画像や HTML など、公開ツールが受け付けない内容が含まれていないことを確認してください。

表示してから公開する

タグ付けするバージョン、リリースノート、コミットをユーザーに表示します。 ユーザーがこのリリースを依頼し、リリースノートを確認したか、確認せずに公開するよう指示した場合にのみ公開します。

1. main ブランチで、以前のリリースコミットのスタイル（git log --oneline -- releases/）に従い、ディスクリプターのみをコミットして、ブランチをプッシュします。通常のファストフォワードプッシュのみを使用し、強制プッシュは決して行いません。
2. 手動で公開するプラットフォームがあれば、最初に公開します。プロジェクト独自のコマンドを使用し、認証情報またはユーザーのマシン（署名付き macOS ビルドの場合は Mac など）が必要な場合は、ユーザーが実行します。コマンドを正確に伝えます。そのコマンドがバージョンタグを作成する場合は、そのまま作成させてから、タグがディスクリプターのコミットを指していることを確認します。
3. main が更新されておらず、引き続きグリーンであることをもう一度確認します。そのコミットにまだタグが付いていなければタグを付け、そのタグのみをプッシュします：git push origin v<version>。--force と --tags は決して使用しません。--tags を使うと、不要なローカルタグもすべてプッシュされてしまいます。

監視と検証

1. タグのプッシュによって開始された実行を見つけ（gh run list --workflow <file>）、監視します（gh run watch <id>）。
2. 成功したら、リリースを確認します（gh release view v<version>）。プレリリースではありません。CI でビルドされたすべてのプラットフォームのパッケージ、署名、更新マニフェストが含まれています。リリースノートにはそのテキストが使われています。
3. 「latest」が何を指しているか確認します。 インストール済みのビルドは、最新リリースのエイリアス経由で更新フィードを読み込むことがよくあるため、それが最新の安定版に解決されることを確認します（タグを指定せずに gh release view --json tagName を実行）。古い系列のパッチを latest にしてはいけません。別のリリースが指定されている場合は、変更する前にそのことを伝えます。変更すると、インストール済みのすべてのビルドに提示される内容が変わります。
4. アプリが読み込むエイリアス経由で更新マニフェストを取得し、このバージョンと、ダウンロード可能なパッケージが記載されていることを確認します。
5. 実行とリリースのリンク、バージョンとビルド番号、手動で公開した分の成果、確認で見つかった問題を報告します。

ビルドに失敗した場合

タグは移動できないため、タグを変更せずに失敗を修正します。

• 一時的な失敗（ランナーの障害、ネットワークのタイムアウトなど）：失敗したジョブを再実行します（gh run rerun <id> --failed）。同じタグとリリースノートで再度ビルドし、公開ステップではその実行が生成したファイルのみを置き換える必要があります。
• シークレットまたは環境の不足：ユーザーが作成してから、失敗したジョブを再実行します。新しいタグは不要です。
• コード修正が必要な失敗：このタグからこのバージョンをビルドすることはできません。修正済みコミットから、独自のディスクリプターを使って次のパッチバージョンを作成するよう推奨します。失敗したバージョンの手動公開分についてユーザーに確認します。すでに公開済みの場合は、パッチが公開されるまでプラットフォーム間で差異が生じるため、パッチのリリースノートに修正内容を記載する必要があります。