Bruchänderungen

Diese Dokumentation erklärt, wie man bei Änderungen in der App mit versionierten Kanälen umgeht. 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 sich vorstellen:

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

Empfohlener Ansatz: Setze ein defaultChannel für jede Hauptversion. Dies stellt sicher, dass Sie immer Updates an bestimmte Benutzergruppen pushen können, 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'

Tipp

Vorteile dieser Ansatz:

• Immer die Kontrolle über welche Benutzer Updates erhalten
• Keine dynamische Kanalwechsel notwendig in Ihrer App code
• Klare Trennung zwischen verschiedenen App-Versionen
• Flexibilität um Updates an jede spezifische 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

Aktualisieren Sie Ihre Capacitor-Konfiguration, bevor Sie die 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 "initially"-Wert gesetzt haben defaultChannel benutzen Sie die "1.x"-Kanal. Für zukünftige Hauptversionen setzen Sie immer einen spezifischen Kanal wie production z.B. "2.x", "3.x", etc. v3, v43. Verwalten Sie separate __CAPGO_KEEP_0__-Zweige

Abschnitt mit dem Titel "3. Verwalten Sie separate Code-Zweige"

Terminalfenster

# 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

Stellen Sie sicher, dass Sie keine JavaScript-Bundles an ältere Apps pushen, die native __CAPGO_KEEP_0__/APIs erwarten, die sie nicht haben. Bauen Sie immer Updates von dem entsprechenden Zweig aus: Never push JavaScript bundles to older apps that expect native code/APIs they don’t have. Always build updates from the appropriate branch:

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

4. Upload-Bundles auf die jeweiligen Kanäle

# 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 dem App Store bereitstellen

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 er im App-Bundle konfiguriert ist.

Hinweis

Keine code-Änderungen erforderlich! 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 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
    }
  }
};

Sie können nun Updates für jede Version pushen:

• 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)

Nachdem 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 v2-Kanal:

npx @capgo/cli channel delete v2

3. Löschen Sie den v1-Wartungsbranch:

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

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 Version 1.x-Updates

Um Aktualisierungen für Version 1.x zu senden:

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 in den Produktionskanal:

npx @capgo/cli bundle upload --channel production

Tip

Halten Sie Ihre v1-maintenance-Zweigstruktur auf dem neuesten Stand mit Bugfixes, die mit Version 1.x kompatibel sind, aber nie Bruchänderungen von main mergen

Weitermachen von Breaking Changes

Wenn Sie Breaking Changes zur Planung von Kanalrouting und staged Rollout verwenden, verbinden Sie es mit Channels für die Implementierungsdetails in Channels, Channels für die Implementierungsdetails in Channels, Channels für die Implementierungsdetails in Channels, Beta-Testlösung für den Produktworkflow in Beta-Testlösung, und Versionziel-Lösung für den Produktworkflow in Versionziel-Lösung.