11. Breaking Changes

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

Stellen wir uns vor:

• App-Version 1.2.3 (alte Version) - verwendet den Produktionskanal
• App-Version 2.0.0 (neue Version mit Änderungen, die den Updateprozess beeinflussen) - verwendet den Kanal v2
• Live-Update 1.2.4 (kompatibel mit 1.2.3)
• Live-Update 2.0.1 (kompatibel mit 2.0.0)

Strategie: Verwende immer den Standardkanal für Hauptversionen

Empfohlener Ansatz: Eine defaultChannel für jede Hauptversion festlegen. So kannst du immer Updates an bestimmte Benutzergruppen pushen, ohne dich auf dynamische Kanalzuweisungen zu verlassen.

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

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

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

Tip

Vorteile dieser Vorgehensweise:

• Immer die Kontrolle behalten über welche Benutzer Updates erhalten
• Keine dynamische Kanalumstellung in Ihrer App erforderlich code
• Klare Trennung zwischen verschiedenen App-Versionen
• Flexibilität Updates an beliebiger spezifischer Version 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 ein:

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 kein 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 den jeweiligen Kanälen 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.

Hinweis

No code changes needed! Da defaultChannel: 'v2' mit dem App Store-Veröffentlichung verpackt ist, verwenden alle Benutzer, die Version 2.0.0 herunterladen, automatisch den richtigen Kanal.

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. Löschen 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

Tipp

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-Zweigstruktur:

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

Tipp

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 die Funktion verwenden Breaking Changes um die Kanalsteuerung und die geplante Rollout zu planen, verbinden Sie sie mit Kanäle für die Implementierungsdetails in Kanälen Kanäle für die Implementierungsdetails in Kanälen Kanäle für die Implementierungsdetails in Kanälen Beta-Testlösung für den Produktworkflow in Beta-Testlösung und Versionziel-Lösung für den Produktworkflow in Versionziel-Lösung.