メインコンテンツへスキップ
チュートリアル

Capgo のバージョニングの仕組み

Capgo が Capacitor アプリのバージョンをどのように管理しているかを理解し、最大限に活用しましょう。major、minor、patch の意味も学べます。

Capgo のバージョニングの仕組み

Capgo は、Capacitor アプリのバージョン管理に 2 つの主要な変数を使用します:

  • ネイティブバージョン
  • JavaScriptバージョン
Capacitor アップデートシステム

すべてのバージョンの選択は、Capgo によってサーバーサイドで決定されます。

バージョン管理システム

Capgo のバージョン管理には SemVer システムを使用します。詳細は SemVer 仕様書 を確認するか、Capgo のアップデート互換性を Semver Tester.

バージョン

比較対象のバージョンを Capgo が取得する場所

version キーを設定することで、この動作を上書きできます capacitor.config.json ファイル のドキュメントで確認してください。 すべてのプラットフォームにおいて、Native Build のバージョンは無視されます。

iOS

iOS では、変数はプロジェクトのここで設定されます ios/App/App/Info.plist キーの下にCFBundleShortVersionString または ios/App/App.xcodeproj/project.pbxproj キーの下に MARKETING_VERSION もし MARKETING_VERSION が設定されていた Info.plist ファイル。

Android

Androidでは、変数はプロジェクトのここで設定します android/app/build.gradle キーの下に defaultConfig.versionName

JavaScript ( Capgo bundle バージョン )

JavaScriptでは、varを以下のように設定できます。 package.json キーの下に version そうでない場合は、uploadコマンドで指定する必要があります。

デフォルトの挙動

設定を変更していない場合、Capgo channelは次のように動作します。

この挙動は、デフォルトとして作成した固有のchannelに基づきます。

Capacitor appを新規インストールした際、

ユーザーがIonic appを初めてダウンロードして起動すると、Capgo serverに接続されます。

現在、以下の4つの出力パターンがあります:

  • Native bundleのバージョン(1.2.3)がCapgoのbundleバージョン(1.2.4)より低い場合、Capgoはユーザーにbundleを送信します。
  • Native bundleのバージョン(1.2.3)がCapgoのbundleバージョン(1.2.3)と同じ場合、Capgoは「アップデート不要」を返します。
  • Native bundleのバージョン(1.2.4)がCapgoのbundleバージョン(1.2.3)より高い場合、Capgoは「アップデート不要」を返します。
  • Native bundleのバージョン(1.2.3)がCapgoのバージョン(2.2.3)よりMAJORが低い場合、Capgoは「アップデート不要」と判断します。

その他の設定

Native環境での自動ダウングレードを無効化

この設定をfalseにすると、Capgoは常にそのバージョンを信頼できるソースとして扱います。 その場合の挙動は以下の通りです:

  • Nativeのバージョン(1.2.4)がCapgoのバージョン(1.2.3)より高い場合

Capgoは自身のバージョンをユーザーに送信します。

自動アップグレード戦略を無効化

いくつかの戦略から選択できます。詳細についてはこちらをご覧ください こちら

JavaScript bundleのバージョン

JavaScript bundleのバージョンは、以下を実行する際に送信されるものです: npx @capgo/cli@latest bundle upload --channel production

オプションを使用していない場合 --bundle 1.2.3、Capgo はあなたの package.json ファイル(version キー)から bundle バージョンを取得します。

Ionic アプリが Capgo からあるバージョンをインストールすると、そのバージョンが以下の比較対象になります:

  • JavaScript bundle のバージョン (1.2.3) が Capgo の bundle バージョン (1.2.4) より低い場合、Capgo はユーザーに bundle を送信します。

ガード条件は次のとおりです:

  • Native bundle のバージョンが Capgo のバージョンより高い場合、 Disable auto downgrade under native その条件が適用されます。
  • Native bundle のバージョンが Capgo のバージョンより MAJOR バージョン分低い場合、 Disable auto upgrade above major その条件が適用されます。

App Store のアップデート

Capacitor の JS アプリを App Store で公開すると、何が起こるかはシンプルです。

ユーザーはストアから新しいバージョンを取得し、デフォルトではアプリ内のローカルアップデートはすべて削除されます。

この挙動を変更するには、設定を行う必要があります resetWhenUpdate 詳細はこちら こちら

他の設定とは異なり、これはクラウド側ではなくアプリ側でのみ変更可能です。

その他の設定

これらの挙動に加えて、deviceIDに紐づいた特定の挙動を設定することもできます。

Capgo では、deviceIDごとに挙動を上書きするように設定できます。

1つのdeviceIDを以下に紐づけられます:

  • 特定のbundleバージョン
  • 特定のchannel

これにより、上記の設定はすべてバイパスされます。

詳細は以下の記事をご覧ください。

Capgo のバージョン管理の仕組みについて

使用している場合 Capgo のバージョニングの仕組み ネイティブプラグインの作業を計画するには、次と連携してください: Capgo プラグインディレクトリ Capgo プラグインディレクトリのプロダクトワークフローについては、 Capgo による Capacitor プラグイン Capgo による Capacitor プラグインの実装詳細については、 プラグインの追加または更新 プラグインの追加または更新に関する実装詳細については、 Ionic Enterprise プラグインの代替案 Ionic Enterprise Plugin Alternatives のプロダクトワークフロー、および Capgo Native Build Capgo Native Builds のプロダクトワークフローについては、

Capacitor アプリ向けの Live Updates

Web レイヤーのバグが本番で発生したら、App Store の審査を何日も待たずに Capgo で修正を配信しましょう。ネイティブの変更は通常の審査フローに残したまま、ユーザーはバックグラウンドでアップデートを受け取れます。

最新のブログ記事

Capgoは、真にプロフェッショナルなモバイルアプリを作るために必要な最高のインサイトを提供します。