Lors de la publication d'une version majeure
La gestion des versions peut être complexe. En général, vous souhaitez envoyer une mise à jour majeure lorsqu'un changement important apparaît pour les utilisateurs.
Mais le versionnage n'est pas conçu pour cela : la version du store d'applications diffère de la version Native.
La version Native sert à gérer les changements cassants 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
Utilisé par Capgo pour comparer à la version JavaScript et détecter une mise à niveau 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 était défini 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 à la version JavaScript et détecter une mise à jour majeure
sous 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é version dans
capacitor.config.jsonfichier la doc ici
JavaScript
Sera utilisé par Capgo pour comparer à la version Native et détecter une mise à niveau majeure
en JavaScript, la variable var 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 la mise à niveau vers capacitor 4.
Vous devez mettre à jour votre numéro de version vers 2.2.3, puis tous vos packages incluent Capgo avec la mention de ce changement majeur.
Lorsque vous publiez cette version sur Capgo et l'App Store.
Tous les prochains live update dans Capgo 2.2.4 ne seront jamais envoyés à l'utilisateur avec la 1.2.3 version. Uniquement avec la 2.2.3 version.
Si vous suivez ce pattern, pas d'inquiétude : tout est bien géré.
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 Live Updates Capgo pour le workflow produit dans Capgo Live Updates.
