Oleafly をリリースする

Oleafly のリリースは、意図的に 2 つの段階に分かれています。バージョンタグがドラフトをビルドして検証します。メンテナーが、別のワークフローの実行で、同じドラフトを公開します。

main へのプッシュは CI を実行しますが、リリースは作成しません。

ドラフトをビルドする

CI が通っている最新の main ブランチから始めます。

git switch main
git pull --ff-only
./scripts/bump-version.sh 0.3.6
git commit -am "chore: release v0.3.6"
git push origin main
git tag v0.3.6
git push origin v0.3.6

タグが .github/workflows/release.yml を起動します。次のターゲットをビルドします。

ターゲット	インストーラー
macOS Apple Silicon	.dmg
Windows x64	.msi と -setup.exe
Linux x64	.AppImage と .deb
Linux ARM64	.AppImage と .deb

各ターゲットは、固定されたコンパイラのサイドカーを取得して検証します。そのあとワークフローは、4 つのアップデーターのフラグメントすべてを 1 つの latest.json にマージします。必要なインストーラーとアップデーターのエントリがすべてそろったときにだけ、ドラフトは準備完了とみなされます。

ドラフトを確認する

GitHub のリリースページ （新しいタブで開きます）でドラフトを開きます。リリースノート、インストーラーの名前、チェックサム、署名、latest.json を確認します。不完全なドラフトを公開してはいけません。

公開する

Actions → Release → Run workflow を開きます。同じタグを入力して Publish the release を選びます。

公開の実行は、ビルドと成果物のチェックを繰り返します。また、リリース候補を使って、Anthropic と Google に対するライブのコントラクトテストも実行します。サポートするすべてのプラットフォームと、完全なアップデーターのフィードがそろっていなければ、最後のジョブは公開を拒否します。

公開すると、latest.json がインストール済みのアプリから見えるようになります。元に戻せない本番の操作として扱ってください。公開の実行が失敗した場合は、リリースをドラフトのままにして、原因を直してから、もう一度実行します。

バージョン番号

Oleafly はセマンティックバージョニングに従います。

• パッチ: 0.3.5 から 0.3.6 のような変更で、互換性のある修正に使います。
• マイナー: 0.3.5 から 0.4.0 のような変更で、互換性のある機能に使います。
• メジャー: 0.3.5 から 1.0.0 のような変更で、互換性のない変更や、最初の安定版に使います。

重要なチェック

• タグは、package.json、src-tauri/tauri.conf.json、src-tauri/Cargo.toml、src-tauri/Cargo.lock と一致している必要があります。これらを個別に編集するのではなく、scripts/bump-version.sh を使います。
• リリースノートは、CHANGELOG.md の該当するバージョンのセクションから取られます。
• 公開済みのタグを再利用してはいけません。失敗したドラフトは、ブランチを直して新しいバージョンを作ります。未公開のタグを置き換える明確な理由がある場合は例外です。
• macOS の署名と公証には、Apple のリリース用シークレットを使います。Windows の Authenticode は、シークレットが設定されている場合に Azure Artifact Signing を使います。アップデーターの署名には、別の Tauri 署名鍵を使います。

アップデーターの署名とロールバックの動作については、自動アップデートを参照してください。ユーザー向けのインストール手順は、ダウンロードとインストールにあります。