Changements de rupture

Cette documentation explique comment gérer les changements de version dans votre application en utilisant des canaux versionnés. Cette approche permet de maintenir différentes versions de votre application tout en garantissant que les utilisateurs reçoivent des mises à jour compatibles.

Scénario d'exemple

Supposons que vous ayez :

• Version de l'application 1.2.3 (ancienne version) - utilise le canal de production
• Version de l'application 2.0.0 (nouvelle version avec des changements de version) - utilise le canal v2
• Mise à jour en direct 1.2.4 (compatible avec 1.2.3)
• Mise à jour en temps réel 2.0.1 (compatible avec 2.0.0)

Stratégie : Utiliser toujours defaultChannel pour les versions majeures

Approche recommandée : Définir un defaultChannel pour chaque version majeure. Cela vous permet toujours de pousser des mises à jour à des groupes d'utilisateurs spécifiques sans dépendre de l'affectation dynamique de canal.

// Version 1.x releases
defaultChannel: 'v1'

// Version 2.x releases
defaultChannel: 'v2'

// Version 3.x releases (future)
defaultChannel: 'v3'

Conseil

Avantages de cette approche :

• Avoir toujours le contrôle sur les utilisateurs qui reçoivent les mises à jour
• Pas de basculement de canal dynamique nécessaire dans votre application __CAPGO_KEEP_0__ needed in your app code
• entre différentes versions de l'application Flexibilité
• pour envoyer des mises à jour vers n'importe quel groupe de version spécifique 1. Créer un canal pour la nouvelle version

Section intitulée “1. Créer un canal pour la nouvelle version”

# Create channel for version 2.x
npx @capgo/cli channel create v2

Section intitulée “2. Mettre à jour Capacitor Config pour la version 2.0.0”

Mettez à jour votre Capacitor config avant de construire la version 2.0.0 pour la boutique d'applications :

capacitor.config.ts

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  appId: 'com.example.app',
  appName: 'Example App',
  plugins: {
    CapacitorUpdater: {
      // ... other options
      defaultChannel: 'v2' // All 2.0.0 users will use v2 channel
    }
  }
};

export default config;

Remarque

Pour la version 1.x : Si vous n'avez pas défini un defaultChannel initialement, les utilisateurs de la version 1.x sont sur le production canal. Pour les futures versions majeures, définissez toujours un canal spécifique comme v3, v4, etc.

3. Gérer les branches Code séparées

Créez des branches Git séparées pour maintenir la compatibilité entre les versions de l'application :

# Create and maintain a branch for version 1.x updates
git checkout -b v1-maintenance
git push origin v1-maintenance

# Your main branch continues with version 2.x development
git checkout main

Critique : Never push JavaScript bundles to older apps that expect native code/APIs they don’t have. Always build updates from the appropriate branch:

• branche de maintenance v1: Pour les mises à jour des applications 1.x (chaîne de production)
• : Pour les mises à jour des applications 2.x (chaîne v2)4. Télécharger les Bundles dans les Canaux Respectifs

Section intitulée “4. Télécharger les Bundles dans les Canaux Respectifs”

# For 1.x updates: Build from v1-maintenance branch
git checkout v1-maintenance
# Make your 1.x compatible changes here
npx @capgo/cli bundle upload --channel production

# For 2.x updates: Build from main branch
git checkout main
# Make your 2.x changes here
npx @capgo/cli bundle upload --channel v2

5. Activer l'attribution automatique

# Allow apps to self-assign to v2 channel
npx @capgo/cli channel set v2 --self-assign

6. Déployer sur l'App Store

Construire et déployer la version 2.0.0 sur l'App Store. Tous les utilisateurs qui téléchargent cette version (que ce soit de nouveaux utilisateurs ou des utilisateurs existants qui mettent à jour) utiliseront automatiquement le canal v2 car il est configuré dans le bundle de l'application.

Note

No code changes needed! Depuis defaultChannel: 'v2' est fourni avec la version de l'application sur le magasin, tous les utilisateurs téléchargeant la version 2.0.0 utiliseront automatiquement le bon canal.

Échelle vers les futures versions

Lorsque vous publiez la version 3.0.0 avec plus de changements de rupture :

# Create channel for version 3.x
npx @capgo/cli channel create v3

// capacitor.config.ts for version 3.0.0
const config: CapacitorConfig = {
  // ...
  plugins: {
    CapacitorUpdater: {
      defaultChannel: 'v3' // Version 3.x users
    }
  }
};

Vous pouvez maintenant envoyer des mises à jour vers n'importe quelle version :

• production canal → Utilisateurs de la version 1.x
• v2 canal → Utilisateurs de la version 2.x
• v3 canal → Utilisateurs de la version 3.x

7. Nettoyage (Après Migration)

Une fois que tous les utilisateurs ont migré vers la version 2.x (durée de 3-4 mois) :

1. Supprimer defaultChannel de votre Capacitor config
2. Supprimer le canal v2 :

npx @capgo/cli channel delete v2

3. Supprimer la branche v1-maintenance :

git branch -d v1-maintenance
git push origin --delete v1-maintenance

Conseil

Cette approche garantit que les utilisateurs ne reçoivent que des mises à jour compatibles avec leur version d'application

Testez toujours les mises à jour soigneusement dans chaque canal avant la mise en production

Remarque

Vous pouvez supprimer en toute sécurité le canal v2 dans Capgo même si certains utilisateurs ont toujours l'override de canal. Ils recevront automatiquement les mises à jour du canal de production à la place.

Maintenance des Mises à jour de la Version 1.x

Pour envoyer des mises à jour compatibles avec la version 1.x :

1. Passer à la branche v1-maintenance :

git checkout v1-maintenance

2. Appliquez vos modifications et commitez :

# Make 1.x compatible changes
git add .
git commit -m "Fix for v1.x"
git push origin v1-maintenance

3. Construire et envoyer vers le canal de production :

npx @capgo/cli bundle upload --channel production

Conseil

Maintenez votre branch v1 à jour avec les correctifs de bogues compatibles avec la version 1.x, mais n'intégrez jamais les modifications de rupture de la branche principale