Passer à la navigation principale
Tutoriel

Comment les versions fonctionnent dans Capgo

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

Martin Donadieu

Martin Donadieu

Spécialiste du contenu

Comment fonctionnent les versions dans Capgo

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

  • Versions natives
  • Versions JavaScript
Système d'actualisation de Capacitor

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

Système de versionnage

Pour gérer la version Capgo, utilisez le système SemVer, en savoir plus ici Versions.

ici

Où Capgo trouver la version à comparer

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

IOS

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 était défini dans votre Info.plist fichier.

Android

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

JavaScript ( Capgo version du bundle )

Dans JavaScript, la variable peut être définie dans votre package.json sous la clé version Sinon, vous devez la fournir dans la commande d'upload.

Comportement par défaut

Voici comment le canal Capgo se comportera si vous n'avez pas modifié de 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 télécharge votre application Ionic pour la première fois et ouvre l'application, elle se connecte au 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 son bundle à l'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 du bundle natif (1.2.3) est MAJOR inférieure à la version du bundle Capgo (2.2.3), Capgo envoie « pas besoin de mettre à jour ».

Autres paramètres

Désactiver la mise à niveau automatique sous native

Si vous modifiez cette configuration en faux, Capgo considérera toujours comme la source fiable de la version. Ensuite, le comportement devient :

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

Capgo envoie sa version à l'utilisateur.

Désactiver la stratégie de mise à niveau automatique

Vous pouvez choisir parmi plusieurs stratégies. Vous pouvez en savoir plus ici ici

Version du bundle JavaScript

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

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

Après que votre application Ionic ait installé une version de Capgo, c'est cette version qui sera comparée pour :

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

Sous certaines conditions de garde :

  • Si la version du bundle natif est supérieure à la version de Capgo, la Disable auto downgrade under native condition est appliquée.
  • Si la version du bundle natif est inférieure au MAJOR par rapport à la version de Capgo, la condition est appliquée. Disable auto upgrade above major condition d'application

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 l'App Store et supprimera toutes les mises à jour locales dans leur application par défaut.

Si vous souhaitez modifier ce comportement, vous devez configurer la mise en forme resetWhenUpdate En savoir plus Ici

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

Autres paramètres

Après ce comportement, vous pouvez avoir au-dessus de cela certaines spécificités liées à l'ID du dispositif.

Dans Capgo, vous pouvez décider de surcharger le comportement pour chaque ID de dispositif.

Vous pouvez lier un ID de appareil à :

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

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

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

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

Lorsqu'un bug de 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.

Commencez maintenant

Dernières actualités de notre blog

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