Lorsque vous publiez une nouvelle version majeure
La gestion des versions peut être difficile, car vous souhaitez généralement envoyer une mise à jour majeure lorsque des changements majeurs apparaissent pour les utilisateurs.
La versionnage n'est pas fait pour cela, la version de l'app store est différente de la version native.
La version native est conçue pour gérer les changements de rupture dans la code
En iOS, par exemple, iOS 16 est la store version de l'Apple, mais la version code est 20A5283p (ils ne semblent pas utiliser SemVer là-bas)
Maintenant, il est clair que nous ne les confondons pas et les utilisons pour ce qu'elles sont faites !
Mise à jour majeure
Sur votre application Capacitor, une mise à jour majeure est nécessaire lorsque des modifications de rupture se produisent. Par exemple, une nouvelle cible IOS (15 à 16), ou une nouvelle version de Capacitor (3 à 4), ou un plugin (1.2 à 2.0) que vous utilisez ont été mis à jour vers une version majeure.
Cette modification signifie que toutes les outils doivent être alignés pour gérer la modification de rupture.
C'est pourquoi Capgo suit ce système.
Par conséquent, si vous publiez une mise à jour majeure, Capgo ne la transmettra pas à un utilisateur qui n'a pas installé la version la plus récente depuis l'App Store.
Cette comportement peut être personnalisé. Vous pouvez en savoir plus sur cela ici
Versions
Où Capgo trouve la version à comparer
IOS
Utilisé par Capgo pour comparer à la version JavaScript et trouver une mise à jour majeure
Sur IOS, la variable est définie dans votre projet ici ios/App/App/Info.plist sous la cléCFBundleShortVersionString ou ios/App/App.xcodeproj/project.pbxproj sous la clé MARKETING_VERSION si MARKETING_VERSION a été défini dans votre Info.plist fichier.
Vous pouvez contourner ce comportement en définissant la clé de version dans
capacitor.config.jsonfichier Documentation
Android
sera utilisé par Capgo pour comparer à la version JavaScript et trouver une mise à niveau majeure
en Android, la variable est définie dans votre projet ici android/app/build.gradle sous la clé defaultConfig.versionName
Vous pouvez contourner ce comportement en définissant la clé de version dans
capacitor.config.jsonfichier docs ici
JavaScript
Serait utilisé par Capgo pour comparer avec la version Native et trouver une mise à jour majeure.
en JavaScript, la variable est définie dans votre projet ici package.json sous la clé version
Exemple
Votre application Ionic est actuellement publiée avec la version 1.2.3 avec Capacitor 3
Vous effectuez l'upgrade vers capacitor 4.
Vous devez mettre à jour votre numéro de version à 2.2.3Ensuite, tous vos packages incluent Capgo avec un avertissement sur cette grande modification.
Lorsque vous publiez cette version sur Capgo et sur l'App Store.
Tous les prochains live update dans Capgo 2.2.4 ne seront jamais envoyés aux utilisateurs avec 1.2.3 version. Seuls avec 2.2.3 version.
Si vous suivez ce modèle, il n'y a plus besoin de vous inquiéter, tout est bien géré.
Si je ne suit pas ces étapes
Dans ce cas, cela signifie que vous devez envoyer votre nouvelle application avec Capacitor 4 à Apple et Google, mais pas à Capgo.
Ensuite, vous devez attendre que 100 % de vos utilisateurs aient l'application ou au moins 90 %, ce qui prendra des mois, probablement.
While during this time you cannot send any update with Capgo, since old user cannot get the new version. You don’t have a way to select only some users to receive the update.
Continuez de la section Comment publier une version majeure dans capgo
If vous utilisez Comment publier une nouvelle version majeure de capgo pour planifier le rollback et le contrôle de version, connectez-l’à Rollbacks pour les détails d'implémentation dans Rollbacks, Version ciblée pour les détails d'implémentation dans Version Targeting, Mise à jour pour les détails d'implémentation dans Mise à jour, bundle pour les détails d'implémentation dans bundle, et Capgo Mises à jour en temps réel pour le flux de travail du produit dans les mises à jour Capgo Live.
