Sauter au contenu principal
Tutorial

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 Marque 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 de 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 trouve 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é de version dans capacitor.config.json fichier docs ici

Android

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

dans 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

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

dans 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 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 cela

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.

Keep going from How to release major version in capgo

Continuez de la même manière que dans Comment lancer une nouvelle version majeure dans __CAPGO_KEEP_0__ How to release major version in capgo Comment lancer une nouvelle version majeure dans __CAPGO_KEEP_0__ pour planifier le retrait et le contrôle de version, connectez-le avec Rollbacks pour les détails d'implémentation dans Rollbacks, 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 de la couche 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 modifications natives 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 véritablement professionnelle.