Lors de la publication d'une version majeure
La gestion de la version peut être difficile, vous souhaitez généralement envoyer une mise à jour majeure lorsque des changements majeurs apparaissent pour les utilisateurs.
La version de l'application store n'est pas la même que la version native.
La version native est conçue pour gérer les changements de rupture dans la code
Par exemple, sur IOS, iOS 16 est la store version de Apple, mais la version code est 20A5283p (ils ne semblent pas utiliser SemVer là-bas)
Maintenant, il est clair que nous ne les mélangeons pas et les utilisons pour ce qu'elles sont faites !
Sortie majeure
Dans votre application Capacitor, une sortie majeure est nécessaire lorsque se produit un changement de rupture. 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 à une version majeure.
Ce changement signifie que toutes les outils doivent être alignés pour gérer le changement de rupture.
C'est pourquoi Capgo suit ce système.
Par conséquent, si vous faites une sortie majeure, Capgo ne l'envoie pas à un utilisateur qui ne l'a pas installé depuis la boutique.
Ce comportement peut être personnalisé. Vous pouvez en savoir plus sur cela ici
Versions
Où Capgo trouver la version à comparer
IOS
Serait utilisé par Capgo pour comparer à la version JavaScript et trouver une mise à niveau majeure
Dans 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 ou MARKETING_VERSION sous la clé MARKETING_VERSION si Info.plist était défini dans votre
fichier.
capacitor.config.jsonVous pouvez contourner ce comportement en définissant la clé version dans docs ici
Android
Seront utilisés par Capgo pour comparer à la version JavaScript et trouver une mise à jour majeure
sur Android, la variable est définie dans votre projet ici android/app/build.gradle sous la clé defaultConfig.versionName
Vous pouvez surcharger ce comportement en définissant la clé de version dans
capacitor.config.jsonle fichier docs ici
JavaScript
Seront utilisés par Capgo pour comparer à la version Native et trouver une mise à jour majeure
sur 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 faites l'upgrade vers capacitor 4.
Vous devez mettre à jour votre numéro de version vers 2.2.3, puis toutes vos packages incluent Capgo avec un avertissement de ce grand changement.
Lorsque vous publiez cette version sur Capgo et l'App Store.
Tous les prochains mises à jour en direct sur Capgo 2.2.4 ne seront jamais envoyés à l'utilisateur avec 1.2.3 version. Seulement 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 suis pas à la hauteur de ce processus
Dans ce cas, cela signifie que vous devez envoyer votre nouvelle application avec Capacitor 4 chez Apple et Google, mais pas chez Capgo.
Ensuite, vous devez attendre que 100 % de vos utilisateurs aient l'application ou au moins 90 %, ce qui prendra des mois, probablement.
Pendant ce temps, vous ne pouvez pas envoyer d'actualisation avec Capgo, car les anciens utilisateurs ne peuvent pas obtenir la nouvelle version. Vous n'avez pas la possibilité de sélectionner uniquement certains utilisateurs pour recevoir l'actualisation.
Continuez de la même manière que pour la mise à jour majeure de capgo
Si vous utilisez La mise à jour majeure de capgo pour planifier le rollback et le contrôle de version, connectez-l’avec Rollbacks pour les détails d'implémentation dans Rollbacks, Version Targeting pour les détails d'implémentation dans Version Targeting, Comportement de mise à jour pour les détails d'implémentation dans Comportement de mise à jour, bundle pour les détails d'implémentation dans bundle, et Capgo Mises à jour en temps réel for the product workflow in Capgo Live Updates.
