11. Breaking Changes

Diese Dokumentation erklärt, wie Sie bei Änderungen in Ihrer App mit kanalisierten Versionen umgehen können. Diese Vorgehensweise ermöglicht es Ihnen, verschiedene Versionen Ihrer App zu pflegen, während sichergestellt wird, dass Benutzer kompatible Updates erhalten.

Beispiel-Szenario

Lasst man sagen, Sie haben:

• App-Version 1.2.3 (alte Version) - verwendet Produktionskanal
• App-Version 2.0.0 (neue Version mit Änderungen, die das Programm brechen) - 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 defaultChannel für Hauptversionen

Empfehlte Vorgehensweise: Einstellung für jede Hauptversion. Dadurch 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 Vorgehensweise:

• Immer die Kontrolle behalten über welche Benutzer Updates erhalten
• Keine dynamische Kanalwechsel notwendig in Ihrer App __CAPGO_KEEP_0__ needed in your app code
• zwischen verschiedenen App-Versionen Flexibilität
• um Updates an jede spezifische Version zu pushen 1. Kanal erstellen für neue Version

Abschnitt mit dem Titel „1. Kanal erstellen für neue Version“

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

2. Aktualisieren Sie Capacitor-Konfiguration für Version 2.0.0

Aktualisieren Sie Ihre Capacitor-Konfiguration, bevor Sie Version 2.0.0 für den App Store erstellen:

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 Benutzer von Version 1.x, die nicht eine production Kanal. Für zukünftige Hauptversionen setzen Sie immer einen bestimmten Kanal wie v3, v4, usw.

3. Verwalten Sie separate Code Zweige

Erstellen Sie separate Git-Zweige, 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: Pushen Sie niemals JavaScript-Bundles an ältere Apps, die native code/APIs erwarten, die sie nicht haben. Bauen Sie immer Updates von dem entsprechenden Zweig aus:

• Zweig v1-maintenance: Für Updates an 1.x-Apps (Produktionskanal)
• Hauptzweig: Für Updates auf 2.x Apps (Kanal v2)

4. Bundles in 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 deployen

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

Hinweis

No code changes needed! Seitdem defaultChannel: 'v2' wird mit der App-Store-Version verbunden, werden alle Benutzer, die Version 2.0.0 herunterladen, automatisch die richtige 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 pushen:

• production Kanal → Benutzer der Version 1.x
• v2 Kanal → Benutzer der Version 2.x
• v3 Kanal → Benutzer der 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 v2-Kanal:

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

Tip

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, bevor Sie sie bereitstellen

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 versenden, die mit Version 1.x kompatibel sind:

1. Wechseln Sie zur 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 in die Produktionskanal:

npx @capgo/cli bundle upload --channel production

Tipps

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

Weitermachen von Breaking Changes

Wenn Sie "Breaking Changes" verwenden, um Kanalrouten und die Stufenrollout zu planen, verbinden Sie es mit Breaking Changes zum Planen von Kanalrouten und der Stufenrollout Channels zur Implementierungsdetail in Channels Channels zur Implementierungsdetail in Channels Channels zur Implementierungsdetail in Channels Beta-Testlösung für das Produktworkflow in Beta-Testlösung und Versionziel-Lösung für das Produktworkflow in Versionziel-Lösung.