Capgo Semver Tester
__CAPGO_KEEP_0__のセマンティックバージョン互換性をチェックする
「ネイティブ基準バージョン」って何?
ネイティブ基準バージョンは、Capgo に送信されるネイティブ アプリのバージョンです。
version_build デバイスがアップデート サーバーにバンドルを要求するときに、Capacitor アプリでは、その値は
CapacitorUpdater.version から得られます。 その設定が存在しない場合、プラグインは iOS または Android からネイティブ アプリのバージョンを取得します。 そのバージョンを仮定しないでください。 それを config またはネイティブ メタデータにコピーするようにビルドを実行する場合除きます。 capacitor.config.*__CAPGO_KEEP_0__ はまだ使用しています package.json
Major: blocks target major greater than version_build. Allows 1.2.3 -> 1.9.0, blocks 1.2.3 -> 2.0.0.
Capgo still uses version_name ダウンロードしたバンドルの現在のインストール状況を知ることができます。 major, minorChannel semver ポリシーなど
patch リモートのバンドルと version_build.
Capacitor 設定
Set CapacitorUpdater.version アプリが送信する特定のバージョンを指定したい場合
Pro: iOS と Android のビルドで同じを維持するのが簡単です。
Con: 設定を更新するのを忘れて、古い設定がバージョンを誤って報告する可能性があります。
ネイティブアプリのバージョン
プラットフォームのバージョンを使用する、例えば iOS CFBundleShortVersionString またはAndroid
versionName.
Pro: TestFlight、App Store、Play Store、または内部テストからインストールされたバイナリユーザーと一致します。
Con: リリース設定が異なる場合、プラットフォームごとに異なるため、ネイティブビルドが必要になります。
Bundleターゲット
リモートバンドルバージョン、チャンネルsemverルール、またはアップロード制約などと比較します。 --native-version.
Pro: prevents sending JavaScript that needs newer native code to old app binaries.
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.
semver 標準により、Capgo は、各アップデートに含まれる変更内容を正確に理解できます:
- パッチ アップデート (1.0.0 → 1.0.1): バグ修正、自動適用が安全
- マイナー アップデート (1.0.0 → 1.1.0): 新機能、バックワード互換性
- メジャー アップデート (1.0.0 → 2.0.0): 破壊的変更、ネイティブ アプリ ストアのリリースが必要
This prevents Capgo from ever sending an incompatible update to your native code, protecting your users from crashes and ensuring your app remains stable.
Flexible Semver Strategies: Beyond Basic Versioning
While semver is strict about its core format, you can extend it for your team's needs using pre-release identifiers and build metadata:
✍ Build Metadata (+) - The "Cosmetic" Layer
一个为一为很览一为一为很览。 バージョン順位の際に、メタデータは無視されます -
1.2.0+anything equals 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 → 4 分の 1 のリリース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 は semver の優先順位規則を尊重するため、チャネル戦略を計画する必要があります。
__CAPGO_KEEP_0__
1.0.0
✓ 標準リリース
2.1.3-alpha
✓ プリリリース
1.0.0-beta.1
✓ プリリリースに数字
1.0.0+build.1
✓ ビルドメタデータ
1.0.0-rc.1+build.1
✓ 完全なバージョン
__CAPGO_KEEP_0__
v1.0.0
✗ 'v' が先頭にあります
1.0
✗ パッチバージョンが欠落しています
1.0.0.0
✗ バージョン部分が多すぎます
1.0.0-
✗ プリリリースが空です
1.0.0+
✗ ビルドメタデータが空です
Capgo の更新動作
このツールは公式の セマンティック バージョニング規定 npm の実装とは異なります。