Capgo Semver テスター
チェック チャネル ポリシー互換性を、native バaselineとして送信されたバージョン_ビルドに対して
「ネイティブベースラインバージョン」って何?
Native Baseline Version is the native app version sent to Capgo as
version_build その値は、Capacitor アプリの場合、
CapacitorUpdater.version から取得できます。 capacitor.config.*その設定が存在しない場合、プラグインはiOSまたはAndroidからネイティブアプリのバージョンを取得します。 そのバージョンはあなたのバージョンであると仮定しないでください。 その値をconfigまたはネイティブメタデータにコピーするようにビルドを実行する場合除きます。 package.json
__CAPGO_KEEP_0__ はまだ
Capgo still uses version_name ダウンロードしたバンドルの現在のインストール状況を知ることができます。チャネルsemverポリシーなど major, minor, そして
patch リモートのバンドルを version_build.
Capacitor config
設定 CapacitorUpdater.version アプリが送信する明示的なバージョンを1つだけ取得したい場合に使用します。
Pro: iOSとAndroidのビルドで同じバージョンを維持することが簡単です。
Con: 古い設定を忘れてnativeリリース前に更新しないと、間違ったバージョンを報告する可能性があります。
ネイティブアプリのバージョン
プラットフォームバージョンを使用します。例えばiOS 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がセマンティックバージョニングを使用するのか
セマンティックバージョニング 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 →アセットの更新コンテンツ追跡用のクリエイティブメタデータ
⚡ Hotfix ストラテジー
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 がセマンティックバージョニングの規則を厳密に遵守していることです。チャネル戦略を計画する際にご注意ください。
重要なのは、Capgo が厳密なセマンティックバージョニングを使用していることです。
Unlike npm's semver implementation, Capgo follows the official SemVer specification strictly. npm's node-semver has known deviations from the spec, which can cause unexpected behavior.
たとえば、npm はバージョンを 1.0.0-alpha.1
異なる方法で扱います。公式の規定では扱う必要がありません。詳細は
の問題を参照してください。 と
の試み マージされていませんでした。
有効なシーケンスバージョン
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 のアップデート動作
このツールは公式の セマンティックバージョニングの仕様 unlike npm's implementation.