Capgo Semver テスター
version_build として送信された Native Baseline とチャンネルポリシーの互換性を確認します
解決されたチャンネルに割り当てられた bundle バージョン。
「Native Baseline Version」の意味
Native Baseline Versionは、Capgoに送信されるネイティブアプリのバージョンで、具体的には
version_build デバイスがアップデートサーバーにbundleを要求するときの値です。Capacitorアプリでは、この値は次から取得できます
CapacitorUpdater.version における capacitor.config.*。その設定が存在しない場合、プラグインはiOSまたはAndroidのネイティブアプリのバージョンにフォールバックします。それが自分の package.json
バージョンだとは想定しないでください。ビルドでその値をconfigやネイティブのメタデータにコピーしている場合を除きます。
Capgoは引き続き version_name 現在インストールされているダウンロード済みbundleを確認するために使用します。次のようなChannelのsemverポリシーは、 major, minorや
patch リモートのbundleを以下と比較します version_build.
Capacitor の設定
設定 CapacitorUpdater.version アプリから特定のバージョンを明示的に送信したい場合。
メリット: iOSとAndroidのビルド間でバージョンを統一しやすい。
デメリット: ネイティブリリース前に更新を忘れると、古い設定のまま誤ったバージョンが報告される可能性がある。
ネイティブアプリのバージョン
iOSなどのプラットフォームのバージョンを使用 CFBundleShortVersionString またはAndroid
versionName.
メリット: TestFlight、App Store、Play Store、または内部テストからユーザーがインストールしたバイナリと一致します。
デメリット: 変更にはネイティブビルドが必要で、リリース設定がずれるとプラットフォームによって異なる場合があります。
Bundle のターゲット指定
リモート bundle バージョン、チャネルの semver ルール、メタデータアップロードの制約（例： --min-update-version）と比較してください。チャネルでは --disable-auto-update metadata.
メリット: 新しいネイティブ code が必要な JavaScript を古いアプリバイナリに送信することを防ぎます。
デメリット: 厳しすぎるルールは、チャネルや bundle メタデータが調整されるまで有効な更新をブロックする可能性があります。
このテスターでは、デバイスが送信するネイティブベースラインを version_buildとして入力し、Capgo が配信するリモート bundle バージョンと比較してください。
Capgo がセマンティックバージョニングを使う理由
セマンティックバージョニング は、ソフトウェア開発で最も広く採用されているバージョニング標準です。 semver を利用することで、Capgo は Capacitor アプリにライブアップデートを配信する際の互換性と安全性を確保します。
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 の更新ロジックでは。
🔧 プレリリース識別子 (-) - 開発チャンネル
注意: プレリリース版は優先順位が低くなります -
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 → 本番環境へのデプロイデプロイメタデータを用いたバージョニングの自動化
- 互換性に影響しないトラッキングやタイムスタンプ、見た目だけの情報にはビルドメタデータ (+) を使用してください
- 更新の優先順位を変えたい開発チャネルには、プレリリース識別子 (-) を使用してください
- 両方を組み合わせて柔軟性を最大限に高めましょう：
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 ✓ プレリリース 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 のアップデート挙動
このツールは公式の セマンティックバージョニング仕様 を準拠しています。npmの実装とは異なります。