Passer au contenu principal
Tutoriel

Comment lancer une version majeure dans capgo

Comprenez comment et quand il est nécessaire de lancer une version majeure pour votre application sans casser votre application utilisateur

Martin Donadieu

Martin Donadieu

Responsable de la création de contenu

Comment lancer une version majeure dans capgo

Lors de la mise à jour d'une version majeure

La gestion des versions peut être difficile, vous souhaitez généralement envoyer une mise à jour majeure lorsque des changements majeurs apparaissent pour les utilisateurs.

Mais la versionnage n'est pas fait pour cela, la version de l'application sur le magasin est différente de la version native.

La version native est conçue pour gérer les changements de rupture dans l'application 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 survient une modification 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.

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 faites une sortie majeure, Capgo ne la transmettra pas à un utilisateur qui n’a pas installé la version correspondante depuis l’app store.
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 à jour 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 sous la clé MARKETING_VERSION si MARKETING_VERSION avait été défini dans votre Info.plist fichier.

Vous pouvez surcharger ce comportement en définissant la clé version dans capacitor.config.json fichier docs ici

Android

Seront utilisés par Capgo pour comparer à la version JavaScript et trouver les mises à jour majeures

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.json fichier docs ici

JavaScript

Seront utilisés par Capgo pour comparer à la version Native et trouver les mises à jour majeures

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 effectuez 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 sur 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é.

If I don’t follow this

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.

Alors pendant ce temps, vous ne pouvez pas envoyer d'update avec Capgo, puisque les anciens utilisateurs ne peuvent pas obtenir la nouvelle version. Vous n'avez pas de moyen de sélectionner uniquement certains utilisateurs pour recevoir l'update.

Continuez de la section "Comment lancer une version majeure dans capgo"

Si vous utilisez Comment lancer une version majeure dans capgo pour planifier le rollback et le contrôle de version, connectez-le à Rollbacks pour les détails d'implémentation dans Rollbacks, Version Targeting pour les détails d'implémentation dans Version Targeting, Mise à jour du comportement pour le détail d'implémentation dans Mise à jour du comportement, bundle pour le détail d'implémentation dans bundle, et Capgo Mises à jour en temps réel pour le flux de travail du produit dans Capgo Mises à jour en temps réel.

Mises à jour en temps réel pour les applications Capacitor

Lorsqu'un bug du niveau web est en ligne, expédiez la correction par le biais de Capgo au lieu d'attendre des jours pour l'approbation de la boutique d'applications. Les utilisateurs reçoivent la mise à jour en arrière-plan tandis que les changements natifs restent dans la voie de revue normale.

Démarrer maintenant

Dernières actualités de notre Blog

Capgo vous offre les meilleures informations dont vous avez besoin pour créer une application mobile vraiment professionnelle.