Veränderungen, die den Code brechen

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

Beispiel-Szenario

Stellen Sie sich vor, Sie haben:

• 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: Verwenden Sie immer defaultChannel für Hauptversionen

Setzen Sie ein für jede Hauptversion. So können Sie Updates für bestimmte Benutzergruppen immer pushen, ohne auf dynamische Kanalzuweisung angewiesen zu sein. defaultChannel Auf die 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 volle Kontrolle über welche Benutzer Updates erhalten
• Keine dynamische Kanalumstellung notwendig 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. 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 keine defaultChannel anfangs sind die Benutzer der Version 1.x auf dem production Kanal. Für zukünftige Hauptversionen stellen Sie immer einen bestimmten Kanal wie v3, v4usw.

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

• v1-WartungszweigFür Updates an 1.x-Apps (Produktionskanal)
• Hauptzweig: Für Updates für 2.x-Anwendungen (Kanal v2)

4. Bundles auf die jeweiligen Kanäle 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

Build and deploy version 2.0.0 to the App Store. Alle Benutzer, die diese Version herunterladen (ob neue Benutzer oder bestehende Benutzer, die aktualisieren), werden automatisch die v2-Kanal verwenden, da es in der 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' Skalierung für zukünftige Versionen

Abschnitt mit dem Titel „Skalierung für zukünftige Versionen“

Terminal-Fenster

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

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

1. Löschen defaultChannel aus Ihrem Capacitor-Konfiguration
2. Löschen Sie den v2-Kanal:

npx @capgo/cli channel delete v2

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

Sie können die v2-Kanäle 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 die 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 Sie in den Produktionskanal:

npx @capgo/cli bundle upload --channel production

Tipp

Halten Sie Ihre v1-Wartungsbranch aktuell mit Bugfixes, die mit Version 1.x kompatibel sind, aber nie breaking Changes von main mergen.