Capgo Semver テスター
チャンネルポリシー互換性を、バージョン_ビルドとして送信されたネイティブベースラインと確認する
「ネイティブベースラインバージョン」って何?
ネイティブベースラインバージョンは、Capgo に送信されるネイティブアプリのバージョンです。
version_build when the device asks the update server for a bundle. In a Capacitor app, that value can come from
CapacitorUpdater.version Capgo アプリでは、その値は capacitor.config.*から取得できます。 package.json
その設定が存在しない場合、プラグインは iOS または Android からネイティブアプリのバージョンを取得します。
Capgo still uses version_name ダウンロードしたバンドルの現在のインストール状況を知ることができます。チャネルsemverポリシーなど major, minor, そして
patch リモートのバンドルを version_build.
Capacitor 設定
を比較します。 CapacitorUpdater.version Set
アプリが送信する明示的なバージョンを1つだけ取得したい場合に使用します。 Pro:
iOSとAndroidのビルドで同じバージョンを維持することが簡単です。 Con:
設定を更新するのを忘れて、古い設定がバージョンを誤って報告する可能性があります。
ネイティブアプリのバージョン CFBundleShortVersionString またはAndroid
versionName.
Pro: TestFlight、App Store、Play Store、または内部テストからインストールされたバイナリと一致します。
Con: 変更を求めるにはネイティブビルドが必要であり、リリース設定が異なる場合にプラットフォームによって異なる可能性があります。
Bundleターゲット
リモートバンドルバージョン、チャンネルsemverルール、またはメタデータアップロード制約などと比較します。 --min-update-versionチャンネルは --disable-auto-update metadata.
Pro: 古いアプリバイナリに送信する必要があるJavaScriptが新しいネイティブcodeを必要とすることを防止します。
Con: ルールがあまりにも厳密な場合、チャンネルまたはバンドルメタデータを調整するまで有効なアップデートをブロックする可能性があります。
このテスターのために、デバイスが送信するネイティブの基準値を入力してください version_build, その後、Capgo が配信するリモートのバンドルバージョンと比較してください。
なぜCapgoがセマンティックバージョニングを使用するのか
セマンティックバージョニング ソフトウェア開発で最も広く採用されているバージョニング標準です。 セマンティックバージョニングを使用することで、Capgoは、ライブアップデートをあなたのCapacitorアプリに安全かつ互換性のある形で配信することを保証します。
セマンティックバージョニング規格により、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 - 生産用の状態0.x.xを使用して、1.0未満の開発、デザイン追跡用のメタデータ
🏢 エンタープライズ/規制
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 → {{__CAPGO_KEEP_0__}}でリリースされたタイムスタンプテスト用のプレリリース、デプロイメントの追跡用のメタデータ
🌍 複数プラットフォーム戦略
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 → ステージングのデプロイ1.4.0+prod.final.789 → プロダクションのデプロイ自動化されたバージョニングとデプロイメントのメタデータ
- ビルドメタデータを使用して、トラッキング、タイムスタンプ、または互換性に影響しない外観情報を追跡します。
- 開発チャネルが異なるアップデートの優先順位を必要とする場合、プレリリース識別子を使用します。
- 両方を組み合わせて最大限の柔軟性を実現します。
1.2.0-beta.1+ui.dark.theme.20240315 - 重要な点は、Capgoはsemverの優先順位ルールを尊重するため、チャネル戦略を計画する必要があります。
有効なシーケンスバージョン
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 の実装とは異なります