Capgo Semver Tester
version_buildとして送信されたNative Baselineと、チャンネルポリシーの互換性を確認します
「Native Baseline Version」の意味
Native Baseline Versionとは、デバイスがアップデートサーバーにbundleを要求する際に、Capgoへ送信されるネイティブアプリのバージョンです。Capgoアプリでは、この値は
version_build デバイスがアップデートサーバーにbundleをリクエストする際、Capacitor アプリではその値は以下から取得できます。
CapacitorUpdater.version 内の capacitor.config.*バージョンであると想定しないでください。 package.json
ビルド時にその値をconfigやネイティブのメタデータにコピーしない限り、バージョンは反映されません。
Capgoは、現在どのダウンロード済みbundleがインストールされているかを確認するために、引き続き version_name を使用します。次のようなChannelのsemverポリシーは、 major, minor、および
patch リモートのbundleを以下と比較します version_build.
Capacitor 設定
Set CapacitorUpdater.version 設定します。
メリット: iOSとAndroidのビルド間でバージョンを統一しやすい。
デメリット: ネイティブリリースの前に更新を忘れると、古い設定のまま誤ったバージョンが報告される可能性があります。
ネイティブアプリのバージョン
iOSなどのプラットフォームのバージョンを使用 CFBundleShortVersionString またはAndroid
versionName.
メリット: TestFlight、App Store、Play Store、または内部テストからユーザーがインストールしたバイナリと一致します。
デメリット: 変更には Native Build が必要です。また、リリース設定の乖離によりプラットフォーム間で異なる場合があります。
Bundle のターゲット指定
リモートの bundle バージョン、チャンネルの semver ルール、または以下のようなメタデータの upload 制約と比較します: --min-update-versionチャンネルは次を使用する必要があります。 --disable-auto-update metadata.
Pro: 古いアプリのバイナリに対して、より新しい Native code を必要とする JavaScript が送信されるのを防ぎます。
Con: ルールが厳しすぎると、チャンネルや bundle メタデータを調整するまで、有効なアップデートがブロックされる可能性があります。
このテスターでは、デバイスが送信するネイティブのベースラインを version_buildとして入力し、Capgo が配信しようとしているリモートの bundle バージョンと比較してください。
Capgo が Semantic Versioning を採用している理由
セマンティックバージョニング は、ソフトウェア開発において最も広く採用されているバージョニング標準です。 semverを利用することで、Capgo は Capacitor アプリへの Live Update 送信時における互換性と安全性を保証します。
semver 標準により、Capgo は各アップデートに含まれる変更内容を正確に把握できます:
- パッチアップデート (1.0.0 → 1.0.1): バグ修正。自動適用しても安全です
- マイナーアップデート (1.0.0 → 1.1.0): 新機能の追加。後方互換性があります
- メジャーアップデート (1.0.0 → 2.0.0): 破壊的変更。ネイティブアプリのストアリリースが必要です
これにより、Capgo がネイティブの code に対して互換性のないアップデートを送信することを防ぎ、クラッシュからユーザーを守り、アプリの安定性を維持します。
柔軟な Semver 戦略:基本のバージョニングを超えて
semver はその基本フォーマットにおいて厳格ですが、チームのニーズに合わせて以下を使用して拡張できます: プリリリース識別子 と ビルドメタデータ:
🏷️ ビルドメタデータ (+) - 「装飾的」なレイヤー
重要: ビルドメタデータはバージョン比較では無視されます -
1.2.0+anything は等しい 1.2.0 Capgo のアップデートロジックでは
🔧 Pre-release Identifiers (-) - 開発用チャネル
備考: Pre-release版は優先度が低くなります -
1.3.0-beta.1 < 1.3.0
🎯 ハイブリッド方式 - 両方の利点を活用
Semverの実践的なユースケースとチーム戦略
🚀 スタートアップ / 高速開発
0.1.0 - 初期のMVPリリース0.2.0-beta.1 - 新機能のテスト0.2.0+ui.v2 - UIリデザインのメタデータ1.0.0 - 本番環境へのデプロイ1.0未満は0.x.xを使用し、デザイン管理にメタデータを活用
🏢 エンタープライズ / 規制環境
2.1.0 → 四半期ごとのリリース2.1.1+sec.patch.cve2024 → 追跡可能なセキュリティパッチ2.2.0-rc.1+audit.ready → 監査前のリリース候補コンプライアンス用メタデータを備えた厳格なSemver
🎮 ゲーム / クリエイティブアプリ
1.0.0+season.winter.2024 → 季節限定コンテンツ1.1.0+event.halloween → イベント連動機能1.2.0+assets.hd.remaster → アセットの更新コンテンツ追跡用のクリエイティブメタデータ
⚡ ホットフィックス戦略
1.2.0 → 現在のプロダクション環境1.2.1-hotfix.payment → 緊急バグ修正1.2.1+urgent.20240315.1430 → タイムスタンプ付きリリーステスト用のプレリリース、デプロイ追跡用メタデータ
🌍 マルチプラットフォーム戦略
1.3.0+ios.optimized → iOS特化の最適化1.3.0+android.material3 → Androidのデザイン更新1.3.0+web.pwa.ready → PWA機能の拡張同一バージョン、プラットフォーム固有のメタデータ
🔄 CI/CD連携
1.4.0-alpha.1+build.123 → リリース前の自動化1.4.0+deploy.staging.456 → Stagingへのデプロイ1.4.0+prod.final.789 → Productionへのデプロイデプロイメタデータを用いたバージョニングの自動化
- 互換性に影響しない追跡用、タイムスタンプ、または装飾的な情報にはビルドメタデータ (+) を使用してください
- 更新の優先順位を変更する必要がある開発チャネルには、プリリリース識別子 (-) を使用してください
- これらを組み合わせて柔軟性を最大化できます:
1.2.0-beta.1+ui.dark.theme.20240315 - 注意: Capgo は semver の優先順位ルールに従います。チャネル戦略はそれに合わせて計画してください。
重要: Capgo は厳密なセマンティックバージョニングを使用します。
npm の semver 実装とは異なり、Capgo は公式の SemVer 仕様に厳密に従います。npm の node-semver には仕様との既知の乖離があり、予期しない動作を引き起こす可能性があります。
例えば、npm は以下のようなバージョンを 1.0.0-alpha.1
仕様とは異なる方法で扱います。詳細は以下の
報告された Issue と
試行された修正 (マージされませんでした)を参照してください。
有効な Semantic Version
1.0.0
✓ 標準リリース
2.1.3-alpha
✓ Pre-release
1.0.0-beta.1
✓ 数値付きプレリリース
1.0.0+build.1
✓ ビルドメタデータ
1.0.0-rc.1+build.1
✓ 完全なバージョン
無効なセマンティックバージョン
v1.0.0
✗ 先頭の 'v' は使用不可
1.0
✗ パッチバージョンがありません
1.0.0.0
✗ バージョンの要素が多すぎます
1.0.0-
✗ プレリリースが空です
1.0.0+
✗ ビルドメタデータが空です
Capgo のアップデート挙動
このツールは公式の Semantic Versioning仕様に準拠しています npmの実装とは異なります。