リリースとバージョン管理

3つのリポジトリは互いに独立してリリースされており、統合された統一バージョン番号は存在しません。このページではそれぞれの規則を整理し、「ランチャーを更新したのにコアが更新されていない」といった混乱を防ぎます。

バージョン管理方針

プロジェクト	バージョン付与方式	配布形式
コアプログラム	master ブランチのローリング更新（厳密な SemVer なし）	git コミット / Docker イメージ
ランチャー	セマンティックバージョニング（例：2.2.5）	圧縮アーカイブ ＋ 自動更新マニフェスト
Android ホスト	versionCode（タイムスタンプ）＋ versionName（コミット数）	GitHub Release ＋ latest.json
ドキュメントサイト	監査済み commit に追従	静的 Web サイト

コアプログラム

• 更新は master ブランチの最新コミットに追従します。「安定版 tag」の固定保証はありません。
• Docker イメージは Git タグおよび master ブランチのビルド成果物として提供されます。
• WebUI の「更新」画面ではコミット単位で差分が表示されます。

リリース前の最小確認事項：

• [ ] ruff による静的解析を通過していること
• [ ] 関連する単体テストを通過していること
• [ ] config_updater / button_extract / export_api_schema の実行差分がないこと
• [ ] インポートスモークテストを通過していること
• [ ] フロントエンドのビルドおよび Vitest テストを通過していること

ランチャー

項目	規定
バージョン番号	Cargo.toml、tauri.conf.json、CHANGELOG.md の3箇所で同期
Git タグ	2.2.5 形式（v プレフィックスは付けない）
配布成果物	3プラットフォーム向けの tar.xz（国際版および -cn ミラー版）
自動更新	stable.json ＋ mTLS 暗号化ペイロード

チェックリストの詳細はビルドとリリースを参照してください。

Android

項目	規定
versionCode	HEAD コミットのタイムスタンプ（CI 側で max(旧値+1, タイムスタンプ) を算出）
versionName	1.<series>.<X> 形式。ベースラインは GitVersion.kt と CI で同期
アプリ配布物	ABI 別の完全版 APK ＋ デュアル ABI 対応の軽量版 APK
Runtime	rootfs-<abi>.tar.xz ＋ BUILD_MANIFEST
マニフェスト	固定 Release 上の latest.json

ベースラインはコードの現況を基準とします

過去のドキュメント記述と実際のコードベースで数値の乖離が存在する場合があります。リリース作業時は最新の GitVersion.kt を直接確認してください。

ドキュメントサイト

当サイトは npm パッケージとしての公開は行わず、静的サイト成果物のみを生成します。バージョンは監査済みコミットに追従します：

1. ソースコード更新後、各種データ抽出スクリプトを再実行。
2. reference/versions.md 内のコミットハッシュと更新日を改定。
3. npm run check および npm run test:e2e を再実行。
4. サイトをビルドし、成果物（meta、canonical、sitemap 等）を検証。

相互互換性に関する方針

組み合わせ	互換性方針
新版ランチャー ＋ 旧版コア	可能な限り後方互換を維持。必要に応じて更新プロンプトを表示
旧版ランチャー ＋ 新版コア	動作保証外。新プロトコルの欠落により起動失敗の可能性あり
新版 APK ＋ 旧版 Runtime	通常は稼働可能。依存関係に変更がある場合は完全パッケージ更新を推奨
旧版 APK ＋ 新版 Runtime	動作保証外。ホストとのインターフェースプロトコル不一致のリスクあり

「後方互換への努力」は「常時稼働の完全保証」ではありません。異なるコンポーネント間での不具合発生時は、まず同日にリリースされたバージョン同士に揃えてから切り分けを行ってください。

リリース完了後の対応

タスク	担当
CHANGELOG の更新	各リポジトリメンテナ
配布成果物とマニフェストのアップロード	各リポジトリ CI
ドキュメント内バージョン情報の更新	ドキュメントメンテナ
リリース初日の Issue 監視	各メンテナ
障害発生時のロールバック対応	各メンテナ