Breaking Changes

Cette documentation explique comment gérer les changements majeurs dans votre application en utilisant des canaux versionnés. Cette approche vous permet de maintenir différentes versions de votre application tout en vous assurant 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 rupture) - utilise le canal v2
• Mise à jour en direct 1.2.4 (compatible avec 1.2.3)
• Mise à jour en direct 2.0.1 (compatible avec 2.0.0)

Stratégie : Utilisez toujours le canal par défaut pour les versions majeures

Approche recommandée : Configurez un defaultChannel pour chaque version majeure. Cela vous permet de pousser toujours des mises à jour vers des groupes d'utilisateurs spécifiques sans dépendre de l'affectation dynamique du 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 des mises à jour
• Aucun changement de canal dynamique n'est nécessaire dans votre application code
• Séparation claire entre différentes versions de l'application
• Flexibilité pour envoyer des mises à jour à n'importe quelle version spécifique

1. Créer un canal pour la nouvelle version

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

2. Mettre à jour la configuration de Capacitor pour la version 2.0.0

Mettez à jour votre configuration de Capacitor 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 version 1.x sont sur le production chaîne. Pour les futures versions majeures, définissez toujours une chaîne spécifique comme v3, v4, etc.

3. Gérer des Branches Séparées Code

Créez des branches Git séparées pour maintenir la compatibilité entre les versions d'applications :

# 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

Important : Jamais envoyer des paquets JavaScript vers des anciennes applications qui attendent des code/APIs natifs qu'elles ne possèdent pas. Construisez toujours les mises à jour à partir de la branche appropriée :

• branche de maintenance v1-maintenance: Pour les mises à jour des applications 1.x (chaîne de production)
• branch principale: Pour les mises à jour des applications 2.x (canal v2)

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'auto-assignation

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

6. Déployer sur l'App Store

Publiez et déployez 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 à niveau) utiliseront automatiquement le canal v2 car il est configuré dans le bundle de l'application.

Note

No code changes needed! Depuis defaultChannel: 'v2' que la version 2.0.0 est livrée avec l'app store, tous les utilisateurs qui téléchargent cette version utiliseront automatiquement le canal correct.

Échelle vers les futures versions

Lorsque vous publiez la version 3.0.0 avec plus de modifications 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 auront migré vers la version 2.x (durant 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 de maintenance v1 :

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 déploiement

Remarque

You can safely delete the v2 channel in Capgo even if some users still have the channel override. They will automatically receive updates from the production channel instead.

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. Apporter vos modifications et commiter :

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

3. Construire et publier sur le canal de production :

npx @capgo/cli bundle upload --channel production

Conseil

Maintenez votre branchement v1-maintenance à jour avec les correctifs de bogues compatibles avec la version 1.x, mais ne mergez jamais les changements de rupture de la branche principale

Continuez de Breaking Changes

Si vous utilisez Changements de rupture pour planifier la routage des canaux et la mise en scène de la mise à jour, connectez-l’avec Canaux contexte : nom de la fonctionnalité des canaux de mise en production de Capgo. Page/zone : page de marketing des solutions Capgo. Rôle : étiquette de navigation ou élément de navigation court. Vu dans : page solutions/white-label.astro. Clé de message `solutions_white_label_visual_cell2_value` (Valeur de la cellule visuelle Solutions White Label) pour les détails d'implémentation dans Canaux, Canaux contexte : nom de la fonctionnalité des canaux de mise en production de Capgo. Page/zone : page de marketing des solutions Capgo. Rôle : étiquette de navigation ou élément de navigation court. Vu dans : page solutions/white-label.astro. Clé de message `solutions_white_label_visual_cell2_value` (Valeur de la cellule visuelle Solutions White Label) pour les détails d'implémentation dans Canaux,  Solution de Test Beta pour le flux de travail du produit dans la Solution de Test Beta, et Solution de Ciblage de Version pour le flux de travail du produit dans la Solution de Ciblage de Version.