メインコンテンツにジャンプします

Capgo Semver テスター

チャンネルポリシー互換性を、バージョン_ビルドとして送信されたネイティブベースラインと確認する

Capgo にバージョン_ビルドとして送信されたネイティブバージョン、config またはネイティブアプリメタデータから。

解決済みチャンネルに割り当てられたバンドルバージョン

2 つのシーケンスバージョンを入力して比較を表示

「ネイティブベースラインバージョン」って何?

ネイティブベースラインバージョンは、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 Set

アプリが送信する明示的なバージョンを1つだけ取得したい場合に使用します。 Pro:

iOSとAndroidのビルドで同じバージョンを維持することが簡単です。 Con:

設定を更新するのを忘れて、古い設定がバージョンを誤って報告する可能性があります。

ネイティブアプリのバージョン 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がセマンティックバージョニングを使用するのか

セマンティックバージョニング ソフトウェア開発で最も広く採用されているバージョニング標準です。 セマンティックバージョニングを使用することで、Capgoは、ライブアップデートをあなたのCapacitorアプリに安全かつ互換性のある形で配信することを保証します。

セマンティックバージョニング規格により、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+20240315.142530
デプロイメントの追跡用のタイムスタンプ
1.2.0+ui.refresh.dark-mode
デザインチーム向けのUI更新の説明
1.2.0+build.4729.commit.a1b2c3d
CI/CDビルド番号とGitコミット

重要な注意事項: バージョン順位の際に、ビルドメタデータは無視されます - 1.2.0+anything 等しく 1.2.0 Capgoのアップデートロジックでは

🔧 プレリリース識別子(-) - 開発チャンネル

1.3.0-beta.1
ベータテストチャンネル
1.3.0-hotfix.payment
緊急修正ブランチ
1.3.0-feature.newapi
機能ブランチテスト

注目事項: 未リリース版のバージョンは、下位の優先順位を持つ - 1.3.0-beta.1 < 1.3.0

🎯 ハイブリッドアプローチ - 最良の両方の世界

1.3.0-rc.1+ui.redesign.20240315
リリース候補版にUIメタデータとタイムスタンプが含まれる

実用的な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 → {{__CAPGO_KEEP_0__}}でリリースされたタイムスタンプ

テスト用のプレリリース、デプロイメントの追跡用のメタデータ

🌍 複数プラットフォーム戦略

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 → プロダクションのデプロイ

自動化されたバージョニングとデプロイメントのメタデータ

💡 Pro Tips:
  • ビルドメタデータを使用して、トラッキング、タイムスタンプ、または互換性に影響しない外観情報を追跡します。
  • 開発チャネルが異なるアップデートの優先順位を必要とする場合、プレリリース識別子を使用します。
  • 両方を組み合わせて最大限の柔軟性を実現します。 1.2.0-beta.1+ui.dark.theme.20240315
  • 重要な点は、Capgoはsemverの優先順位ルールを尊重するため、チャネル戦略を計画する必要があります。

重要な注意事項: Capgoは厳密な意味的バージョニングを使用します。

npmのsemver実装とは異なり、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 のアップデート動作

マイナー戦略では、同じメジャー.マイナーライン内でパッチ変更が許可されます。たとえば 1.0.0 -> 1.0.1
パッチ戦略では 1.0.0 -> 1.0.1 のようなターゲットバンドルをブロックします。ただし、サフィックス変更のみが許可されます。たとえば 1.0.0-beta.1 -> 1.0.0-beta.2
メジャー戦略では、ネイティブベースラインのメジャー以上のターゲットバンドルをブロックします。たとえば 1.0.0 -> 2.0.0
ダウングレード保護では、フルセムバージョンの優先順位を使用します。したがって、安定した 1.0.0 は 1.0.0-beta.2 より新しいです

このツールは公式の セマンティック バージョニングの仕様 を実装しています。npm の実装とは異なります