メインコンテンツへスキップ

Capgo Semver Tester

version_buildとして送信されたNative Baselineと、チャンネルポリシーの互換性を確認します

configまたはネイティブアプリのメタデータから、version_buildとしてCapgoに送信されるネイティブバージョンです。

解決されたチャンネルに割り当てられたbundleバージョン。

2つのセマンティックバージョンを入力して比較

「Native Baseline Version」の意味

Native Baseline Versionとは、デバイスがアップデートサーバーにbundleを要求する際に、Capgoへ送信されるネイティブアプリのバージョンです。Capgoアプリでは、この値は version_build デバイスがアップデートサーバーにbundleをリクエストする際、Capacitor アプリではその値は以下から取得できます。 CapacitorUpdater.version 内の capacitor.config.*バージョンであると想定しないでください。 package.json ビルド時にその値をconfigやネイティブのメタデータにコピーしない限り、バージョンは反映されません。

Capgoは、現在どのダウンロード済みbundleがインストールされているかを確認するために、引き続き version_name を使用します。次のようなChannelのsemverポリシーは、 major, minor、および patch リモートのbundleを以下と比較します version_build.

Capacitor 設定

Set CapacitorUpdater.version 設定します。

メリット: iOSとAndroidのビルド間でバージョンを統一しやすい。

デメリット: ネイティブリリースの前に更新を忘れると、古い設定のまま誤ったバージョンが報告される可能性があります。

ネイティブアプリのバージョン

iOSなどのプラットフォームのバージョンを使用 CFBundleShortVersionString またはAndroid versionName.

メリット: TestFlight、App Store、Play Store、または内部テストからユーザーがインストールしたバイナリと一致します。

デメリット: 変更には Native Build が必要です。また、リリース設定の乖離によりプラットフォーム間で異なる場合があります。

Bundle のターゲット指定

リモートの bundle バージョン、チャンネルの semver ルール、または以下のようなメタデータの upload 制約と比較します: --min-update-versionチャンネルは次を使用する必要があります。 --disable-auto-update metadata.

Pro: 古いアプリのバイナリに対して、より新しい Native code を必要とする JavaScript が送信されるのを防ぎます。

Con: ルールが厳しすぎると、チャンネルや bundle メタデータを調整するまで、有効なアップデートがブロックされる可能性があります。

このテスターでは、デバイスが送信するネイティブのベースラインを version_buildとして入力し、Capgo が配信しようとしているリモートの bundle バージョンと比較してください。

Capgo が Semantic Versioning を採用している理由

セマンティックバージョニング は、ソフトウェア開発において最も広く採用されているバージョニング標準です。 semverを利用することで、Capgo は Capacitor アプリへの Live Update 送信時における互換性と安全性を保証します。

semver 標準により、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 のアップデートロジックでは

🔧 Pre-release Identifiers (-) - 開発用チャネル

1.3.0-beta.1
Betaテスト用チャネル
1.3.0-hotfix.payment
緊急修正用ブランチ
1.3.0-feature.newapi
機能開発ブランチのテスト

備考: Pre-release版は優先度が低くなります - 1.3.0-beta.1 < 1.3.0

🎯 ハイブリッド方式 - 両方の利点を活用

1.3.0-rc.1+ui.redesign.20240315
UIメタデータとタイムスタンプ付きのRC版

Semverの実践的なユースケースとチーム戦略

🚀 スタートアップ / 高速開発

0.1.0 - 初期のMVPリリース
0.2.0-beta.1 - 新機能のテスト
0.2.0+ui.v2 - UIリデザインのメタデータ
1.0.0 - 本番環境へのデプロイ

1.0未満は0.x.xを使用し、デザイン管理にメタデータを活用

🏢 エンタープライズ / 規制環境

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 → タイムスタンプ付きリリース

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

🌍 マルチプラットフォーム戦略

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 → Stagingへのデプロイ
1.4.0+prod.final.789 → Productionへのデプロイ

デプロイメタデータを用いたバージョニングの自動化

💡 プロのヒント:
  • 互換性に影響しない追跡用、タイムスタンプ、または装飾的な情報にはビルドメタデータ (+) を使用してください
  • 更新の優先順位を変更する必要がある開発チャネルには、プリリリース識別子 (-) を使用してください
  • これらを組み合わせて柔軟性を最大化できます: 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 仕様とは異なる方法で扱います。詳細は以下の 報告された Issue と 試行された修正 (マージされませんでした)を参照してください。

有効な Semantic Version

1.0.0 ✓ 標準リリース
2.1.3-alpha ✓ Pre-release
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 のアップデート挙動

✓ Minor 戦略では、同じ major.minor ライン内のパッチ変更(例: 1.0.0 -> 1.0.1)を許可します。
✓ Patch 戦略では 1.0.0 -> 1.0.1 をブロックします。1.0.0-beta.1 -> 1.0.0-beta.2 のようなサフィックス変更のみを許可します。
✗ メジャー戦略では、Native Buildのベースラインより高いメジャーバージョンを持つbundleを対象にします(例: 1.0.0 -> 2.0.0)
⚠ ダウングレード防止には完全なsemver優先順位を使用するため、安定版の1.0.0は1.0.0-beta.2よりも新しいと判断されます

このツールは公式の Semantic Versioning仕様に準拠しています npmの実装とは異なります。