11. Breaking Changes

Diese Dokumentation erklärt, wie Sie bei Änderungen in Ihrer App mit Hilfe von versionierten Kanälen vorgehen. Diese Methode ermöglicht es Ihnen, verschiedene Versionen Ihrer App zu pflegen, während sichergestellt wird, dass Benutzer kompatible Updates erhalten.

Beispiel-Szenario

Lassen Sie uns annehmen, dass Sie haben:

• App-Version 1.2.3 (alte Version) - verwendet Produktionskanal
• App-Version 2.0.0 (neue Version mit Änderungen, die das Update beeinträchtigen) - verwendet v2-Kanal
• Live-Update 1.2.4 (kompatibel mit 1.2.3)
• Live-Update 2.0.1 (kompatibel mit 2.0.0)

Strategie: Verwenden Sie immer den Standardkanal für Hauptversionen

Empfohlener Ansatz: Einstellung für jede Hauptversion festlegen. So können Sie immer Updates an bestimmte Benutzergruppen pushen, ohne auf dynamische Kanalzuweisung angewiesen zu sein. defaultChannel Zwischenablage kopieren

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

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

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

Tip

Vorteile dieser Ansatz:

• Immer die Kontrolle behalten über welche Benutzer Updates erhalten
• Keine dynamische Kanalwechsel erforderlich in Ihrer App code
• Klare Trennung zwischen verschiedenen App-Versionen
• Flexibilität Updates an jede spezifische Versionsgruppe zu pushen

1. Kanal für neue Version erstellen

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

2. Capacitor-Konfiguration für Version 2.0.0 aktualisieren

Stellen Sie die Capacitor-Konfiguration vor der Erstellung von Version 2.0.0 für den App Store aktualisieren:

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;

Hinweis

Für Version 1.x: Wenn Sie keine defaultChannel anfangs sind Benutzer der Version 1.x auf dem production Für zukünftige Hauptversionen stellen Sie immer einen bestimmten Kanal wie v3, v4usw.

3. Manage Separate Code Branches

Erstellen Sie separate Git-Branches, um die Kompatibilität zwischen Anwendungsversionen aufrechtzuerhalten:

# 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

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

• APIs erwarten, die sie nicht haben. Bauen Sie immer Updates von dem entsprechenden Branch aus:Branch für Updates von 1.x-Anwendungen (Produktionskanal)
• Hauptzweig: Für Updates für 2.x-Anwendungen (Kanal v2)

4. Bundles an die jeweiligen Kanäle hochladen

# 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. Selbstzuweisung aktivieren

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

6. Auf App Store bereitstellen

Die Version 2.0.0 im App Store bereitstellen. Alle Benutzer, die diese Version herunterladen (neue oder bestehende Benutzer, die aktualisieren), verwenden automatisch den Kanal v2, da dieser im App Bundle konfiguriert ist.

Anmerkung

No code changes needed! Da defaultChannel: 'v2' ist mit der App Store-Version verbunden, werden alle Benutzer, die Version 2.0.0 herunterladen, automatisch den richtigen Kanal verwenden.

Skalierung für zukünftige Versionen

Wenn Sie Version 3.0.0 mit weiteren Änderungen veröffentlichen:

# 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
    }
  }
};

Jetzt können Sie Updates für jede Version bereitstellen:

• production Kanal → Benutzer von Version 1.x
• v2 Kanal → Benutzer von Version 2.x
• v3 Kanal → Benutzer von Version 3.x

7. Reinigung (Nach der Migration)

Sobald alle Benutzer auf Version 2.x migriert sind (ca. 3-4 Monate):

1. Entfernen defaultChannel aus Ihrer Capacitor-Konfiguration
2. Löschen Sie den Kanal v2:

npx @capgo/cli channel delete v2

3. Löschen Sie den v1-maintenance-Zweig:

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

Tipps

Diese Vorgehensweise stellt sicher, dass Benutzer nur Updates erhalten, die mit ihrer App-Version kompatibel sind

Testen Sie Updates immer gründlich in jedem Kanal vor der Bereitstellung

Hinweis

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.

Erhaltung von Version 1.x-Updates

Um Updates zu senden, die mit Version 1.x kompatibel sind:

1. Wechseln Sie auf die v1-maintenance-Branche:

git checkout v1-maintenance

2. Machen Sie Ihre Änderungen und committen Sie:

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

3. Bauen und hochladen Sie auf den Produktionskanal:

npx @capgo/cli bundle upload --channel production

Tipps

Halten Sie Ihre v1-Wartungsbranchen auf dem neuesten Stand mit Bugfixes, die mit Version 1.x kompatibel sind, aber nie Breaking Changes von main mergen

Weiter von Breaking Changes

Wenn Sie Breaking Changes verwenden Breaking Changes um die Kanalsteuerung und die geplante Rollout zu planen, verbinden Sie es mit Kanäle Kanäle für die Implementierungsdetails in Kanäle Kanäle für die Implementierungsdetails in Kanäle Kanäle Beta-Testlösung für das Produktworkflow in Beta-Testlösung, und Versionziel-Lösung für das Produktworkflow in Versionziel-Lösung.