Änderungen in neuen Versionen

Dieses Dokument beschreibt, wie Sie bei Änderungen in Ihrer App mit kanalisierten Versionen umgehen. Diese Methode 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 Code brechen) - 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 Standardkanal für Hauptversionen verwenden

Empfohlene Vorgehensweise: Set ein defaultChannel für jede Hauptversion. Dies sichert Ihnen, 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'

Tip

Vorteile dieser Vorgehensweise:

• Immer die Kontrolle über welche Benutzer Updates erhalten
• Keine dynamische Kanalwechsel 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 add v2

2. Capacitor-Konfiguration für Version 2.0.0 aktualisieren

Stellen Sie Ihre Capacitor-Konfiguration vor der Erstellung von Version 2.0.0 für den App Store an:

capacitor.Konfigurationsdatei.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;

Anmerkung

Für Version 1.x: Wenn Sie kein Update für die Live-Updates-App konfiguriert haben defaultChannel initialisiert haben, sind Benutzer von Version 1.x auf dem production Kanal. Für zukünftige Hauptversionen stellen Sie immer einen bestimmten Kanal wie v3, v4, usw. ein.

3. Verwalten Sie separate Code Branchen

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

Critical: Vermeiden Sie es, JavaScript-Bundles an ältere Apps zu pushen, die native code/APIs nicht unterstützen. Bauen Sie immer Updates von der entsprechenden Zweig ab:

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

4. Hochladen von Bundles in 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. In die App Store deployen

Die 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! Da defaultChannel: 'v2' es mit der App Store-Version verbunden ist, werden alle Benutzer, die Version 2.0.0 herunterladen, automatisch den richtigen Kanal verwenden.

Skalierung 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 add 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. Säubern (Nach Migration)

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

npx @capgo/cli channel delete v2

3. Löschen Sie den Zweig v1-maintenance:

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

Hinweis

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

Erhaltung von Version 1.x-Updates

Um Updates abzusenden, 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 Sie Ihre Änderungen und committen Sie sie:

npx @capgo/cli bundle upload --channel production

Tipp

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

Fortsetzen von Breaking Changes

Wenn Sie verwenden Änderungen mit Auswirkungen um Kanalrouting und staged Rollout zu planen, verbinden Sie es mit Kanäle zur Implementierungsdetail in Kanäle, Kanäle Für die Implementierungsdetails in den Kanälen, Kanäle Für die Implementierungsdetails in den Kanälen, kontinuierliche Beta-Testlösung Für die Produktworkflow in der kontinuierlichen Beta-Testlösung, und Version Targeting Solution Für die Produktworkflow in der Versionziel-Lösung.