Allez directement au contenu principal
Tutoriel

Comment fonctionnent les versions dans Capgo

Comprenez comment Capgo gère les versions dans votre application Capacitor, et utilisez-l’au mieux. Apprenez l'importance des majeures, mineures et de correction.

Crédits de l'article

Martin Donadieu

Écrivain

Valeria

Relecteur

Jordan

Éditeur

Comment fonctionnent les versions dans Capgo

Capgo utilise 2 variables principales pour gérer les versions dans votre Capacitor application :

  • Version native
  • Versions JavaScript
Système d'actualisation de Capacitor

Toutes les options de version sont décidées côté serveur par Capgo.

Le système de versionnage

Pour gérer la version Capgo utilisez le système SemVer. Lisez la La spécification SemVer ou vérifiez la compatibilité de la mise à jour Capgo. Testeur de Semver.

Les versions

Où Capgo trouver la version à comparer

Vous pouvez contourner ce comportement en définissant la clé de version dans capacitor.config.json le fichier docs La version native sera ignorée pour tous les plateformes.

IOS

In 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éfinie dans votre Info.plist fichier.

Android

In Android, la variable est définie dans votre projet ici android/app/build.gradle sous la clé defaultConfig.versionName

JavaScript ( Capgo version de bundle )

In JavaScript, la variable peut être définie dans votre package.json en dessous de la clé version Sinon, vous devez le fournir dans la commande d'upload.

Comportement par défaut

C'est ainsi que le canal Capgo se comportera si vous n'avez pas modifié les paramètres.

Ce comportement sera basé sur le canal unique que vous avez défini par défaut.

Lors d'une installation fraîche de votre application Capacitor

Lorsque l'utilisateur a téléchargé votre application Ionic pour la première fois et ouvre l'application, elle contacte le serveur Capgo.

Actuellement, 4 résultats peuvent se produire :

  • La version du bundle natif (1.2.3) est inférieure à la version du bundle Capgo (1.2.4), Capgo envoie le bundle au utilisateur.
  • La version du bundle natif (1.2.3) est égale à la version du bundle Capgo (1.2.3), Capgo envoie “pas besoin de mettre à jour”.
  • La version du bundle natif (1.2.4) est supérieure à la version du bundle Capgo (1.2.3), Capgo envoie « pas besoin de mettre à jour ».
  • La version de bundle native (1.2.3) est MAJOR inférieure à la version de bundle Capgo (2.2.3), Capgo envoie “pas besoin de mettre à jour”.

Paramètres supplémentaires

Désactiver la mise à jour automatique native

Si vous modifiez cette configuration pour qu'elle soit fausse, Capgo considérera toujours cette source comme étant fiable pour la version. Ensuite, le comportement deviendra :

  • La version native (1.2.4) est supérieure à la version Capgo (1.2.3)

Capgo envoie sa version à l'utilisateur.

__CAPGO_KEEP_0__ envoie sa version à l'utilisateur.

Il existe plusieurs stratégies dont vous pouvez choisir. Vous pouvez en savoir plus sur cela. here

Version du bundle JavaScript

La version du bundle JavaScript est celle que vous envoyez lors de l'exécution npx @capgo/cli@latest bundle upload --channel production

Si vous n'avez pas utilisé l'option --bundle 1.2.3, Capgo récupérera la version du bundle de votre package.json le fichier (dans la clé de version).

Après l'installation d'une version de votre application Ionic Capgo, c'est cette version qui sera comparée pour :

  • La version de leur bundle JavaScript (1.2.3) est inférieure à la version de bundle Capgo (1.2.4), Capgo envoie son bundle à l'utilisateur.

Avec certaines conditions de garde :

  • Si la version de bundle native est supérieure à la version Capgo, la Disable auto downgrade under native condition est appliquée.
  • Si la version de bundle native est MAJOR inférieure à la version Capgo, la Disable auto upgrade above major condition est appliquée.

Mise à jour de l'App Store

Lorsque vous publiez votre application JS Capacitor sur l'App Store, ce qui se passe est simple.

Votre utilisateur recevra la nouvelle version depuis le magasin et supprimera toutes les mises à jour locales dans leur application par défaut.

Si vous souhaitez modifier ce comportement, vous devez configurer la resetWhenUpdate En savoir plus à ce sujet Ici

Cela ne peut être modifié que côté application, et non depuis le cloud comme les autres paramètres.

Les autres paramètres

Après tout cela, vous pouvez avoir au-dessus quelques comportements spécifiques liés à l'ID du dispositif.

In Capgo, vous pouvez décider de contourner le comportement pour chaque ID du dispositif.

Vous pouvez lier un ID de dispositif à :

  • une version de bundle spécifique
  • un canal spécifique

Cela contournera tous les paramètres effectués ci-dessus.

En savoir plus à ce sujet dans l'article ci-dessous.

Continuez de How version work in Capgo

Si vous utilisez Comment fonctionnent les versions dans Capgo pour planifier le travail de plugin natif, connectez-l’à Capgo Répertoire de plugins pour le flux de travail du produit dans Capgo Répertoire de plugins, Capacitor Plugins par Capgo pour les détails d'implémentation dans Capacitor Plugins par Capgo, Ajouter ou Mettre à jour les plugins pour les détails d'implémentation dans Ajouter ou Mettre à jour les plugins, Alternatives de plugins d'entreprise Ionic pour le flux de travail du produit dans les alternatives du plugin Enterprise Ionic Capgo Bâtiments natifs pour le flux de travail du produit dans les Capgo Builds natifs.

Mises à jour instantanées pour les applications Capacitor

When a web-layer bug is live, ship the fix through Capgo instead of waiting days for app store approval. Users get the update in the background while native changes stay in the normal review path.

Dernières de notre Blog

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