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

Capgo Semver テスター

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

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

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

ネイティブベースラインバージョン_ビルドの最小要件

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

ネイティブベースラインバージョンは、Capgo に送信されるネイティブアプリのバージョンです。 version_build デバイスがアップデートサーバーにバンドルを要求するとき。 Capacitor アプリでは、その値は CapacitorUpdater.version in capacitor.config.* から取得できます。 package.json がある場合、その値が使用されます。

Capgo はまだ使用しています version_name ではありません。 major, minor ではありません。 patch ではありません。 version_build.

Capacitor は、ダウンロードしたバンドルが現在インストールされているかどうかを判断するために

Set CapacitorUpdater.version アプリが明示的に指定したバージョンを送信したい場合。

Pro: iOSとAndroidのビルドを同じに維持するのが簡単。

Con: 設定が古くなって、リリース前に更新しなかった場合、間違ったバージョンが報告される可能性があります。

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

プラットフォームのバージョンを使用します。例えば、iOS CFBundleShortVersionString またはAndroid versionName.

Pro: テストフライト、App Store、Play Store、または内部テストからインストールしたバイナリのユーザーに一致します。

Con: 変更はネイティブのビルドが必要であり、リリース設定が異なる場合、プラットフォームによって異なる可能性があります。

バンドル対象

リモートバンドルバージョン、チャンネルsemverルール、またはメタデータアップロード制約と比較する --min-update-version。チャンネルは --disable-auto-update metadata.

Pro: 古いアプリバイナリに送信する必要があるJavaScriptが新しいネイティブcodeを必要とすることを防ぐ

Con: ルールがあまりにも厳密な場合、有効なアップデートがブロックされるまで、チャンネルまたはバンドルメタデータを調整する必要がある

このテスターで、デバイスが送信するネイティブの基準値を入力し、リモートバンドル バージョンと比較する version_buildなぜCapgoがセマンティックバージョニングを使用するのか

Capgoはセマンティックバージョニングを使用する理由

ソフトウェア開発で最も広く採用されているバージョニング標準です。 semverを使用することで、__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.

semver標準では、Capgoが各アップデートに含まれる変更を正確に理解できるようにします:

  • Patchアップデート (1.0.0 → 1.0.1): バグ修正、自動適用可能
  • Minorアップデート (1.0.0 → 1.1.0): 新機能、バックワード互換
  • Majorアップデート (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-β.1
ベータテストチャネル
1.3.0-ホットフィックス.決済
緊急修正ブランチ
1.3.0-機能.新API
機能ブランチテスト

注意: プレリリース版は、低い優先順位を持つ - 1.3.0-beta.1 < 1.3.0

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

1.3.0-rc.1+UIリデザイン.20240315
リリース候補版とUIメタデータとタイムスタンプ

現実世界のsemver使用例とチーム戦略

🚀 起動 / 速成開発

0.1.0 1.0版の最初のリリース
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 順序規則を尊重するため、チャンネル戦略を計画する必要があります。

Important: 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-ベータ.2 より新しいです。

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