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

How to release major version in capgo

アプリを破壊しないようにユーザー アプリをリリースするために、どのようにして何時にメジャーバージョンをリリースする必要があるかを理解する

記事のクレジット

マーティン・ドナディュー

ライター

バレリア

レビュアー

ジョーダン

編集者

How to release major version in capgo

メジャーバージョンのリリース方法

バージョニングは管理が難しいことがあります。通常、ユーザーにメジャーチェンジが見られる場合にメジャーアップデートを送りたいのです。

しかし、バージョニングはその用途ではありません。アプリストアのバージョンはネイティブバージョンとは異なります。

ネイティブバージョンは、 code

IOSの例では、IOS 16は store version のものですが、codeバージョンは 20A5283p (そこではSemVerを使用していないようです)

今、混同しないようにして、各バージョンをその用途で使用することに気づきました!

メジャーリリース

In your Capacitor app, a major release is necessary when a breaking change happens. For example, a new IOS target (15 to 16), or a new version of Capacitor (3 to 4), or a plugin (1.2 to 2.0) you use have been updated to a major version.

この変更は、すべてのツールを破壊的な変更を処理できるように調整する必要があります。

That why Capgo follows this system. So if you release a major version, Capgo will not send it to a user who doesn’t have it installed from the store.
したがって、主なバージョンをリリースした場合、__CAPGO_KEEP_1__ はストアからインストールしていないユーザーに送信されない。 この動作はカスタマイズできます。詳しくはこちらを参照してください。

バージョン

Capgo はどのバージョンを比較するかを決定します。

iOS

Capgo は JavaScript バージョンと比較して iOS バージョンを使用します。

iOS では、プロジェクトのここで変数を設定します。 ios/App/App/Info.plist キーCFBundleShortVersionString または ios/App/App.xcodeproj/project.pbxproj if MARKETING_VERSION or MARKETING_VERSION Capgoでメジャーバージョンをリリースする方法 Info.plist ファイルに設定されました。

この動作を上書きするには、ファイルのversionキーを設定してください。 capacitor.config.json ファイル ここにドキュメントがあります。

Android

CapgoがJavaScriptバージョンと比較してメジャーアップグレードを検出するために使用されます。

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

この動作を上書きするには、ファイルのversionキーを設定してください。 capacitor.config.json ファイル ここにドキュメントがあります。

JavaScript

CapgoでNativeバージョンと比較し、メジャーアップグレードを検出するために使用されます。

JavaScriptの場合、プロジェクトのここで変数が設定されます package.json キー version

現在、Ionicアプリはバージョン 1.2.3 Capacitor 3

capacitor 4にアップグレードすることです。

バージョン番号をアップグレードする必要があります 2.2.3, すべてのパッケージがCapgoに注意してこの大きな変更を含めるようにします。

このバージョンをCapgoとApp Storeにリリースするとき

Capgoのすべての次のライブアップデート 2.2.4 ユーザーに送ることは決してありません。 1.2.3 __CAPGO_KEEP_0__ のみ。 2.2.3 __CAPGO_KEEP_1__ の場合。

このパターンに従うことで、心配する必要はありません。すべてが適切に処理されます。

このパターンに従わない場合。

この場合、Capacitor の新しいアプリを Apple と Google に送りますが、Capgo に送らないでください。

すると、100% のユーザーがアプリを使用しているか、少なくとも 90% のユーザーがアプリを使用していることを待たなければなりません。これは、数か月かもしれません。

この期間中、Capgo の更新を送ることはできません。古いユーザーは新しいバージョンを受け取ることができません。 また、古いユーザーだけに更新を送る方法もありません。

capgo のメジャーバージョンをリリースする方法については、続きます。

__CAPGO_KEEP_0__ を使用している場合。 capgo を使用してロールバックとバージョン管理を計画する方法については、こちらの記事を参照してください。 __CAPGO_KEEP_0__ を使用してロールバックとバージョン管理を計画する方法については、こちらの記事を参照してください。 ロールバック ロールバックの実装詳細 バージョン対象 バージョン対象 バージョン対象の実装詳細 更新動作 更新動作の実装詳細 バンドル Capgo Live Updates Capgo ライブアップデート

Capacitorアプリのリアルタイム更新

CapgoのWeb層のバグが生じた場合、修正をアプリストアの承認待ちの日数を待たずにCapgoで配信する。ユーザーはバックグラウンドで更新を受け取り、ネイティブの変更は通常のレビュー経路で進む。

マーティンから人間のサポート

今すぐ始めよう

最新のブログ記事

Capgoは、プロフェッショナルなモバイルアプリを作成するために必要な最良の洞察を提供します。