メジャーバージョンをリリースする際
バージョニングの管理は難しい場合があります。通常、ユーザーにとって大きな変更がある場合にメジャーアップデートを送信したいと考えます
しかし、バージョニングはそのために作られたものではありません。App Storeのバージョンは、ネイティブバージョンとは異なります
ネイティブバージョンはコードの破壊的変更を管理するために作られています
例えばiOSでは、iOS 16は Appleのストアバージョンですが、コードバージョンは20A5283pです（彼らはそこでSemVerを使用していないようです）
これらを混同せず、それぞれの目的に応じて使用することが重要です！
メジャーリリース
Capacitorアプリでは、破壊的変更が発生した際にメジャーリリースが必要です 例えば、新しいiOSターゲット（15から16）、新しいバージョンのCapacitor（3から4）、または使用しているプラグイン（12から20）がメジャーバージョンにアップデートされた場合です
この変更は、破壊的変更に対応するためにすべてのツールを調整する必要があることを意味します
そのためCapgoはこのシステムに従っています
メジャーバージョンをリリースする場合、Capgoはストアからインストールしていないユーザーにはそれを送信しません
この動作はカスタマイズ可能です。詳細はこちらで確認できます
バージョン
Capgoがバージョンを比較する場所
iOS
JavaScriptバージョンと比較してメジャーアップグレードを見つけるためにCapgoによって使用されます
iOSでは、変数はios/App/App/InfoplistのCFBundleShortVersionStringキー、またはInfoplistファイルでMARKETING_VERSIONが設定されている場合はios/App/Appxcodeproj/projectpbxprojのMARKETING_VERSIONキーで設定されます
この動作は
capacitorconfigjsonファイルでversionキーを設定することでオーバーライドできます ドキュメントはこちら
Android
JavaScriptバージョンと比較してメジャーアップグレードを見つけるためにCapgoによって使用されます
Androidでは、変数はandroid/app/buildgradleのdefaultConfigversionNameキーで設定されます
この動作は
capacitorconfigjsonファイルでversionキーを設定することでオーバーライドできます ドキュメントはこちら
JavaScript
ネイティブバージョンと比較してメジャーアップグレードを見つけるためにCapgoによって使用されます
JavaScriptでは、変数はpackagejsonのversionキーで設定されます
例
現在、Capacitor 3でバージョン123のIonicアプリがリリースされています
Capacitor 4にアップグレードする場合
バージョン番号を223にアップグレードする必要があります。そうすることで、Capgoを含むすべてのパッケージがこの大きな変更に気付きます
このバージョンをCapgoとApp Storeにリリースすると
次のCapgoのライブアップデート224は、123バージョンのユーザーには送信されず、223バージョンのユーザーにのみ送信されます
このパターンに従えば、心配する必要はなく、すべてが適切に処理されます
このパターンに従わない場合
この場合、Capacitor 4の新しいアプリをAppleとGoogleに送信する必要がありますが、Capgoには送信しません
その後、ユーザーの100%、または少なくとも90%が新しいアプリを入手するのを待つ必要があります。これには数ヶ月かかる可能性があります
この間、古いユーザーは新しいバージョンを取得できないため、Capgoでアップデートを送信することはできません アップデートを受け取るユーザーを選択する方法もありません
