Capgo Semver テスター
チェンネル ポリシー互換性を、native バイナリベースラインとして送信されたバージョン_ビルドと比較します
解決済みチャンネルに割り当てられたバンドル バージョンです。
What "Native Baseline Version" means
Native Baseline Version is the native app version sent to Capgo as
version_build when the device asks the update server for a bundle. In a Capacitor app, that value can come from
CapacitorUpdater.version iOSまたはAndroidのネイティブアプリのバージョンにフォールバックする設定が存在しない場合、プラグインはiOSまたはAndroidのネイティブアプリのバージョンを使用します。 capacitor.config.*__CAPGO_KEEP_0__の値をconfigまたはネイティブメタデータにコピーすることを保証することはできません。 package.json
__CAPGO_KEEP_0__は依然として
Capgo still uses version_name Channel semverポリシー、 major, minor、
patch を使用して、リモートバンドルを__CAPGO_KEEP_0__のconfigと比較します。 version_build.
Capacitor config
を使用して、1つの明示的なバージョンをアプリが送信する場合に使用します。 CapacitorUpdater.version Pro:
iOSとAndroidのビルドで同じを維持することが簡単です。 __CAPGO_KEEP_0__の値をconfigまたはネイティブメタデータにコピーすることを保証することはできません。
Con: 古い設定ファイルを使用すると、バージョンを正しく報告できなくなる可能性がある。
ネイティブアプリのバージョン
プラットフォームのバージョンを使用します。例えば、iOS CFBundleShortVersionString またはAndroid
versionName.
Pro: テストフライト、App Store、Play Store、または内部テストからインストールされたバイナリのバージョンと一致する。
Con: 変更を加えるにはネイティブビルドが必要であり、リリース設定が異なる場合にプラットフォームによって異なる可能性がある。
バンドルターゲット
リモートバンドルバージョン、チャネルsemverルール、またはアップロード制約などと比較する。 --native-version.
Pro: codeを古いアプリバイナリに送る必要があるJavaScriptを送信しないようにする。
Con: 規則が過度に厳密な場合、チャンネルまたはパッケージメタデータを調整するまで、有効な更新をブロックする可能性があります。
このテスターの場合、デバイスが送信するネイティブの基準値を入力し、
それを、リモートパッケージのバージョンと比較してください。 version_buildCapgoがセマンティックバージョニングを使用する理由
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:
- バグ修正、自動適用が安全です マイナーアップデート（1.0.0 → 1.1.0）：
- __CAPGO_KEEP_0__ 新機能、バックワード互換性
- メジャーアップデート（1.0.0 → 2.0.0）： 破壊的な変更、ネイティブアプリストアのリリースが必要
これにより、Capgoは、ネイティブのcodeに不互換なアップデートを送信することがなくなるため、クラッシュを防ぎ、安定したアプリを保証する。
柔軟なSemver戦略：基本的なバージョニングの超え方
semverは、基本的なフォーマットについて厳格ですが、チームのニーズに合わせて拡張することができます。 pre-release識別子 と ビルドメタデータ:
🏷️ ビルドメタデータ（+） - 「外観」レイヤー
重要: バージョン順位のためにビルドメタデータは無視されます -
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 - 製品用 Readiness0.x.x を使用して 1.0 未満の開発、デザイン追跡用のメタデータ
🏢 Enterprise / Regulated
2.1.0 → 4 か月ごとのリリース2.1.1+sec.patch.cve2024 → セキュリティパッチと追跡2.2.0-rc.1+audit.ready → 検査前リリース候補Strict semver に従い、コンプライアンスメタデータを含む
🎮 ゲーミング / クリエイティブ アプリ
1.0.0+season.winter.2024 → 季節のコンテンツ1.1.0+event.halloween → イベント駆動機能1.2.0+assets.hd.remaster → アセットの更新コンテンツ追跡用のクリエイティブ メタデータ
⚡ Hotfix Strategy
1.2.0 → 現在のリリース1.2.1-hotfix.payment → Critical bug fix1.2.1+urgent.20240315.1430 → タイムスタンプ付きでリリーステスト用のプレリリース、デプロイメントトラッキング用のメタデータ
🌍 Multi-Platform Strategy
1.3.0+ios.optimized → iOS用の最適化1.3.0+android.material3 → Android用のデザインの更新1.3.0+web.pwa.ready → PWAの機能同じバージョン、プラットフォーム固有のメタデータ
🔄 CI/CD Integration
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 は厳密な意味的バージョニングを使用します。
有効なシーケンスバージョン
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 の実装とは異なります。