Breaking Changes

Diese Dokumentation erklärt, wie Sie bei Änderungen in Ihrer App mit kanalverteilten 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

Lassen Sie uns sagen, Sie haben:

• App-Version 1.2.3 (alte Version) - verwendet Produktionskanal
• App-Version 2.0.0 (neue Version mit Änderungen, die den Kompatibilität gefährden) - verwendet Kanal v2
• Live update 1.2.4 (kompatibel mit 1.2.3)
• Live update 2.0.1 (kompatibel mit 2.0.0)

Strategie: Immer den defaultChannel für Hauptversionen verwenden

Empfehlung: Einen defaultChannel pro jede Hauptversion. Dies stellt sicher, dass Sie immer Updates an bestimmte Benutzergruppen pushen können, ohne sich auf die dynamische Kanalzuweisung zu verlassen.

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

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

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

Tipps

Vorteile dieser Strategie:

• Immer die Kontrolle haben über die Nutzer erhalten Updates
• Keine dynamische Kanalwechsel benötigt in Ihrer App code
• Klare Trennung zwischen verschiedenen App-Versionen
• Flexibilität Updates an jede spezifische Versionsgruppe 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

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 initial, sind Benutzer von Version 1.x auf dem 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-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: Nie JavaScript-Bundles an ältere Apps pushen, die native code/APIs erwarten, die sie nicht haben. Bauen Sie immer Updates von dem entsprechenden Branch ab:

• Branch für Updates von 1.x-Anwendungen (Produktionskanal)Branch für Updates von 2.x-Anwendungen (v2-Kanal)
• 4. Hochladen von Bundles in den entsprechenden KanälenAbschnitt mit dem Titel “4. Hochladen von Bundles in den entsprechenden Kanälen”

4. Upload Bundles to Respective Channels

# 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 zum App Store bereitstellen. Alle Benutzer, die diese Version herunterladen (ob neue Benutzer oder bestehende Benutzer, die aktualisieren), werden automatisch die v2-Kanal verwenden, da dies im App-Bundle konfiguriert ist.

Hinweis

Keine code-Änderungen erforderlich! Seitdem defaultChannel: 'v2' wird es mit der App-Store-Version verbunden, werden alle Benutzer, die Version 2.0.0 herunterladen, automatisch die richtige Kanal verwenden.

Zu zukünftigen Versionen skalieren

Wenn Sie Version 3.0.0 mit mehreren Bruchä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 → Version 1.x-Benutzer
• v2 Kanal → Version 2.x-Benutzer
• v3 Kanal → Version 3.x-Benutzer

7. Säubern (Nach der Migration)

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

1. Löschen defaultChannel aus Ihrem Capacitor-Konfiguration
2. Löschen des v2-Kanals:

npx @capgo/cli channel delete v2

3. Löschen des v1-Maintenance-Zweigs:

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

Tipp

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

Jedes Update sollte sorgfältig in jedem Kanal getestet werden, bevor es veröffentlicht wird

Hinweis

Sie können den v2-Kanal in Capgo sicher löschen, selbst wenn einige Benutzer noch den Kanal-Übertrag haben. Sie werden automatisch Updates vom Produktionskanal erhalten.

Wartung von Updates für Version 1.x

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

1. Zum v1-Wartungsbranch wechseln:

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. Erstellen und hochladen Sie in den Produktionskanal:

npx @capgo/cli bundle upload --channel production

Tipp

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

Weitergehen von Breaking Changes

Wenn Sie Breaking Changes um das Kanalrouting und die rollierende Veröffentlichung zu planen, verbinden Sie es 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 der Beta-Testlösung, und Versionziel-Lösung für den Produktworkflow in der Versionziel-Lösung.