Lors de la publication d'une version majeure
Le versionnage peut être difficile à gérer ; en général, vous voulez envoyer une mise à jour majeure lorsqu'un changement important apparaît pour les utilisateurs.
Mais le versionnage n'est pas fait pour cela : la version du store est différente de la version native.
La version native est conçue pour gérer les breaking changes dans le code
Sur iOS, par exemple, iOS 16 est la store version d'Apple, mais la version code est 20A5283p (ils ne semblent pas y utiliser le SemVer)
Maintenant, c'est clair : ne les mélangez pas et utilisez-les pour ce pour quoi ils sont faits !
Release majeure
Dans votre application Capacitor, une release majeure est nécessaire lorsqu'un breaking change survient. 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 a été mis à jour vers une version majeure.
Ce changement implique que tous les outils doivent être alignés pour gérer ce breaking change.
C'est pourquoi Capgo suit ce système.
Ainsi, si vous publiez une version majeure, Capgo ne l'enverra pas à un utilisateur qui ne l'a pas installée depuis le store.
Ce comportement peut être personnalisé. Vous pouvez en savoir plus ici
Versions
Où Capgo trouve la version à comparer
iOS
Sera utilisé par Capgo pour comparer avec la version JavaScript et identifier la mise à jour majeure
Sur iOS, la variable est définie ici dans votre projet ios/App/App/Info.plist sous la cléCFBundleShortVersionString ou ios/App/App.xcodeproj/project.pbxproj sous la clé MARKETING_VERSION si MARKETING_VERSION était définie dans votre Info.plist fichier.
Vous pouvez contourner ce comportement en définissant la clé version dans
capacitor.config.jsonfichier la doc ici
Android
Sera utilisé par Capgo pour comparer avec la version JavaScript et identifier une mise à jour majeure
sur Android, la variable est définie ici dans votre projet android/app/build.gradle sous la clé defaultConfig.versionName
Vous pouvez contourner ce comportement en définissant la clé version dans
capacitor.config.jsonfichier la doc ici
JavaScript
Sera utilisé par Capgo pour comparer avec la version native et identifier une mise à jour majeure
en JavaScript, la variable est définie ici dans votre projet 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 la mise à niveau vers capacitor 4.
Vous devez mettre à jour votre numéro de version vers 2.2.3, puis tous vos packages incluront Capgo pour signaler ce changement majeur.
Lorsque vous publierez cette version sur Capgo et l'App Store.
Tous les prochains live update dans Capgo 2.2.4 ne seront jamais envoyés aux utilisateurs avec la 1.2.3 version. Uniquement avec la 2.2.3 version.
En suivant ce schéma, plus besoin de s'inquiéter, tout est géré correctement.
Si je ne respecte pas cela
Dans ce cas, cela signifie que vous devez envoyer votre nouvelle app avec Capacitor 4 à Apple et Google, mais pas à Capgo.
Ensuite, vous devez attendre que 100 % de vos utilisateurs aient l'app, ou au moins 90 % ; cela prendra probablement des mois.
Pendant ce temps, vous ne pouvez envoyer aucune mise à jour avec Capgo, car les anciens utilisateurs ne peuvent pas obtenir la nouvelle version. Vous n'avez aucun moyen de sélectionner uniquement certains utilisateurs pour recevoir la mise à jour.
Continuer avec « Comment publier une version majeure dans capgo »
Si vous utilisez Comment publier une version majeure dans capgo pour planifier le rollback et le contrôle de version, connectez-l’à Rollbacks pour les détails d'implémentation dans Rollbacks, Ciblage de version pour les détails d'implémentation dans Version Targeting, Comportement de mise à jour pour les détails d'implémentation du comportement des mises à jour, bundle pour les détails d'implémentation du bundle, et Capgo Live Updates pour le workflow produit dans Capgo Live Updates.
