Modifiche di Rottura

Copia un prompt di configurazione con i passaggi di installazione e la guida markdown completa per questo plugin.

Questa documentazione spiega come gestire le modifiche di versione nell'applicazione utilizzando i canali versionati. Questa approccio consente di mantenere diverse versioni dell'applicazione, garantendo che gli utenti ricevano aggiornamenti compatibili.

Scenario di esempio

Supponiamo di avere:

Versione dell'applicazione 1.2.3 (versione vecchia) - utilizza il canale di produzione
Versione dell'applicazione 2.0.0 (nuova versione con modifiche di versione) - utilizza il canale v2
Aggiornamento in tempo reale 1.2.4 (compatibile con 1.2.3)
Aggiornamento in tempo reale 2.0.1 (compatibile con 2.0.0)

Strategia: Utilizza sempre defaultChannel per le versioni maggiori

Approccio consigliato: Imposta un defaultChannel per ogni versione maggiore. Ciò ti consente di poter sempre inviare aggiornamenti a specifiche fasce di utenti senza dover ricorrere all'assegnazione dinamica del canale.

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

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

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

1. Crea canale per nuova versione

# Create channel for version 2.x
npx @capgo/cli channel create v2

2. Aggiorna Capacitor Config per Versione 2.0.0

Aggiorna il tuo Capacitor config prima di costruire la versione 2.0.0 per la store dell'applicazione:

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;

Sezione intitolata “3. Gestisci rami separati Code”

Crea rami Git separati per mantenere la compatibilità tra versioni dell'app:

# 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

Critico: Non inviare mai i bundle JavaScript alle app più vecchie che aspettano API native code che non hanno. Costruisci sempre gli aggiornamenti dalla branca appropriata:

Branca di manutenzione v1: Per gli aggiornamenti alle app 1.x (canale di produzione)
: Per gli aggiornamenti alle app 2.x (canale v2)4. Carica i bundle nei canali rispettivi

Sezione intitolata “4. Carica i bundle nei canali rispettivi”

# 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. Abilita l'assegnazione automatica

# Allow apps to self-assign to v2 channel
npx @capgo/cli channel set v2 --self-assign

6. Distribuisci sull'App Store

Costruisci e distribuisci la versione 2.0.0 sull'App Store. Tutti gli utenti che scaricano questa versione (siano nuovi utenti o utenti esistenti che effettuano un aggiornamento) utilizzeranno automaticamente il canale v2 perché è configurato nel bundle dell'applicazione.

Scaling to Future Versions

Quando rilasciate la versione 3.0.0 con più modifiche di rottura:

# 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
    }
  }
};

Ora potete inviare aggiornamenti a qualsiasi versione:

production canale → Utenti della versione 1.x
v2 canale → Utenti della versione 2.x
v3 canale → Utenti della versione 3.x

7. Pulizia (Dopo la migrazione)

Una volta che tutti gli utenti sono stati migrati alla versione 2.x (conteggio 3-4 mesi):

Elimina defaultChannel dalla tua Capacitor configurazione
Elimina il canale v2:

npx @capgo/cli channel delete v2

Elimina la branca v1-maintenance:

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

Testare sempre le nuove versioni attentamente in ogni canale prima della distribuzione

Aggiornamento delle versioni 1.x

Per inviare aggiornamenti compatibili con la versione 1.x:

Passa al ramo v1-maintenance:

git checkout v1-maintenance

Fai le tue modifiche e committa:

# Make 1.x compatible changes
git add .
git commit -m "Fix for v1.x"
git push origin v1-maintenance

Costruisci e carica nel canale di produzione:

npx @capgo/cli bundle upload --channel production

Continua da qui: Modifiche breaking

Se stai utilizzando Modifiche breaking per pianificare la routing dei canali e la distribuzione in fasi, connettilo con Canali per i dettagli di implementazione in Canali, Canali per i dettagli di implementazione in Canali, Canali per i dettagli di implementazione in Canali, Soluzione di Test Beta per il flusso di lavoro del prodotto in Soluzione di Test Beta, e Soluzione di Targeting della Versione per il flusso di lavoro del prodotto in Soluzione di Targeting della Versione.