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_KEEP_0__ アプリでは、その値は capacitor.config.*から得られます。 package.json
その設定が存在しない場合、プラグインはiOSまたはAndroidのネイティブアプリのバージョンにフォールバックします。
Capgo still uses version_name __CAPGO_KEEP_0__ は major, minorを使用して、ダウンロードしたバンドルの現在のインストール状況を知ることができます。
patch チャネルシーケンスバージョンポリシー、 version_build.
Capacitor config
使用したい場合の、1 つの明示的なバージョンをアプリが送信するように設定します。 CapacitorUpdater.version Pro:
iOS と Android のビルドで同じを維持しやすい。 Con:
古い設定が、リリース前に更新を忘れても、誤ったバージョンを報告する可能性があります。 ネイティブアプリのバージョン
プラットフォームのバージョンを使用します。例えば、iOS
または Android CFBundleShortVersionString Pro:
versionName.
テストフライト、App Store、Play Store、または内部テストからインストールしたユーザーがインストールしたバイナリと一致します。 Con:
__CAPGO_KEEP_0__ プラットフォームによって異なる場合、リリース設定がズレている場合、ネイティブのビルドが必要になります。
バンドル対象
リモートバンドルのバージョンを比較する、チャンネルsemverルール、またはアップロード制約などを指定してください。 --native-version.
Pro: 古いアプリバイナリに送る必要があるネイティブのcodeが新しいJavaScriptを必要とする場合に送信しないようにします。
Con: ルールがあまりにも厳密な場合、チャンネルまたはバンドルメタデータを調整するまで、有効なアップデートをブロックする可能性があります。
このテスターに、デバイスが送信するネイティブのベースラインを入力し、リモートバンドルのバージョンと比較してください。 version_buildなぜCapgoがセマンティックバージョニングを使用するのか
Why Capgo uses Semantic Versioning
ソフトウェア開発における最も広く採用されているバージョニング標準です。 セマンティックバージョニングを使用することで、__CAPGO_KEEP_0__は、ライブアップデートを__CAPGO_KEEP_1__アプリに安全かつ互換性のある形で提供できるようにします。 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.
The semver standard allows Capgo to understand exactly what changes are included in each update:
- Patch updates (1.0.0 → 1.0.1): Bug fixes、自動適用可能な安全な修正
- Minor updates (1.0.0 → 1.1.0): 新機能、バックワード互換性あり
- Major updates (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 前リリース識別子 および 構築メタデータ:
🏷️ ビルド メタデータ (+) - "外観"層
重要: ビルドメタデータはバージョン順位の際に無視されます -
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 は semver 順序規則を尊重するため、チャネル戦略を計画する際に注意してください
重要: Capgo は厳格な意味のバージョニングを使用します。
npm の semver implementation と異なり、Capgo は公式の SemVer 規格を厳密に実装しています。 npm の node-semver は、規定と異なる知られている逸脱があり、これにより予期せぬ動作が発生する可能性があります。
たとえば、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 アップデートの動作
このツールは公式 セマンティック バージョニング規格 を実装しているが、npmの実装とは異なります。