Capgo Semver Tester
チャンネルポリシー互換性を、バージョン_ビルドとして送信されたネイティブベースラインと比較します。
「ネイティブベースラインバージョン」って何?
ネイティブベースラインバージョンは、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 指定したバージョンをアプリから送信したい場合に使用します。
メリット: iOSとAndroidのビルドで同じバージョンを維持することが簡単です。
欠点: 設定を更新するのを忘れて、古い設定がバージョンを誤って報告する可能性があります。
ネイティブアプリのバージョン
プラットフォームのバージョンを使用します。たとえば、iOS CFBundleShortVersionString またはAndroid
versionName.
Pro: TestFlight、App Store、Play Store、または内部テストからインストールされたバイナリにマッチします。
Con: 変更を求めるにはネイティブビルドが必要であり、リリース設定が異なる場合にプラットフォームによって異なる可能性があります。
バンドル対象
リモートバンドルバージョン、チャンネルsemverルール、またはメタデータアップロード制約などと比較します。 --min-update-versionチャンネルは --disable-auto-update metadata.
Pro: 古いアプリバイナリに送信する必要があるJavaScriptが新しいネイティブcodeを必要とすることを防止します。
Con: ルールがあまりにも厳密な場合、チャンネルまたはバンドルメタデータを調整するまで有効なアップデートをブロックする可能性があります。
このテスターのために、デバイスが送信するネイティブの基準値を入力してください。 version_build、リモートのバンドルバージョンと比較してください
Capgo が配信したいバージョン。
なぜCapgoがセマンティックバージョニングを使用するのか
セマンティックバージョニング is the most widely adopted versioning standard in software development. By using semver, Capgo ensures compatibility and safety when delivering live updates to your Capacitor apps.
セマンティックバージョニング規範では、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 → タイムスタンプ付きでリリーステスト用のプレリリース、展開トラッキング用のメタデータ
🌍 複数プラットフォーム戦略
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 がセマンティックバージョニングの順位付け規則を尊重していることです。チャンネル戦略を計画する際にご注意ください。
有効なシーケンスバージョン
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 の実装とは異なります