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 Folgendes annehmen:

• App-Version 1.2.3 (alte Version) - verwendet den Produktionskanal
• App-Version 2.0.0 (neue Version mit Änderungen, die den Code 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: Immer Default-Channel für Hauptversionen verwenden

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

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

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

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

Tip

Vorteile dieses Ansatzes:

• Immer die Kontrolle über die Benutzer haben, die Updates erhalten
• Keine dynamische Kanalwechsel benötigt in Ihrer App code
• Klare Trennung zwischen verschiedenen App-Versionen
• Flexibilität um Updates an jede spezifische Versionsgruppe zu pushen

1. Erstellen Sie einen Kanal für die 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 die Version 2.0.0 für den App Store erstellen:

capacitor.Konfiguration.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 keinen bestimmten Kanal festgelegt haben, sind Benutzer von Version 1.x ursprünglich auf dem defaultChannel Kanal. Für zukünftige Hauptversionen müssen Sie immer einen bestimmten Kanal wie production etc. festlegen. v3, v43. Separate __CAPGO_KEEP_0__ Branchen verwalten

Abschnitt mit dem Titel „3. Separate Code Branchen verwalten“

Create separate git branches to maintain compatibility between app versions:

# 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 JavaScript-Bundles niemals an ältere Apps, die native code/APIs nicht unterstützen. Bauen Sie immer Updates von der entsprechenden Branch ab:

• Branch für Updates von 1.x-Apps (Produktionskanal)Branch für Updates von 2.x-Apps (v2-Kanal)
• 4. Hochladen von Bundles in die entsprechenden KanäleAbschnitt mit dem Titel „4. Hochladen von Bundles in die entsprechenden Kanäle“

Terminalfenster

# 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. In den 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-Kanäle verwenden, da dies im App-Bundle konfiguriert ist.

Hinweis

Keine code-Änderungen erforderlich! Da es mit der App-Store-Version verbunden ist, werden alle Benutzer, die Version 2.0.0 herunterladen, automatisch den richtigen Kanal verwenden. defaultChannel: 'v2' Seit

Zukunftssicherung für zukünftige Versionen

Wenn Sie die Version 3.0.0 mit mehreren Ä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 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

Tipp

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

Jede Aktualisierung gründlich in jedem Kanal vor der Bereitstellung testen

Hinweis

Sie können den Kanal v2 in Capgo auch dann sicher löschen, wenn einige Benutzer noch den Kanal überschrieben haben. Sie werden automatisch Updates vom Produktionskanal erhalten.

Aktualisierungen für Version 1.x aufrechterhalten

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

1. Zum v1-maintenance-Zweig 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 die Produktionskanal:

npx @capgo/cli bundle upload --channel production

Tipp

Halten Sie Ihre v1-maintenance-Zweigstruktur 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 zur Planung von Kanalrouting und staged Rollout verwenden, verbinden Sie es mit Kanäle für die Implementierungsdetails in Kanäle, Kanäle für die Implementierungsdetails in Kanäle, Kanäle für die Implementierungsdetails in Kanäle, Beta-Testlösung für den Produktworkflow in Beta-Testlösung, und Versionziel-Lösung für den Produktworkflow in Versionziel-Lösung.