Cambiamenti di versione

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

Immaginiamo di avere:

• Versione dell'app 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
• Live update 1.2.4 (compatibile con 1.2.3)
• Live update 2.0.1 (compatibile con 2.0.0)

Strategia: Utilizzare sempre defaultChannel per le versioni maggiori

Approccio consigliato: Definisci un defaultChannel per ogni versione maggiore. Ciò garantisce di poter sempre inviare aggiornamenti a specifiche fasce di utenti senza dover contare sulla destinazione dinamica dei canali.

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

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

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

Tip

Benefici di questo approccio:

• Rimani sempre in controllo su quali utenti ricevono gli aggiornamenti
• No switching canale dinamico Non è necessario il cambio canale dinamico nell'applicazione code
• Separazione chiara tra le diverse versioni dell'applicazione
• Flessibilità per inviare aggiornamenti a qualsiasi gruppo di versione specifico

1. Crea un canale per la nuova versione

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

2. Aggiorna Capacitor Config per la versione 2.0.0

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

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;

Nota

Per la versione 1.x: Se non hai impostato un defaultChannel inizialmente, gli utenti della versione 1.x sono su production canale. Per le versioni maggiori future, impostare sempre un canale specifico come v3, v4, etc.

3. Gestisci rami separati Code

Creare rami Git separati per mantenere la compatibilità tra versioni dell'applicazione:

# 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

Cruciale: Never push JavaScript bundles to older apps that expect native code/APIs they don’t have. Always build updates from the appropriate branch:

• ramo v1-maintenance: Per gli aggiornamenti alle app 1.x (canale di produzione)
• ramo principale: Per gli aggiornamenti alle app 2.x (canale v2)

4. Carica i pacchetti nei rispettivi canali

# 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. Pubblica su App Store

Esegui la costruzione e la pubblicazione della versione 2.0.0 su 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.

Nota

No code changes needed! Since defaultChannel: 'v2' è inclusa nella versione dell'app store, tutti gli utenti che scaricano la versione 2.0.0 utilizzeranno automaticamente il canale corretto.

Aggiornamento per Versioni Future

Quando rilasciate la versione 3.0.0 con più modifiche di compatibilità:

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

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 saranno migrati alla versione 2.x (circa 3-4 mesi):

1. Elimina defaultChannel dalla tua Capacitor configurazione
2. Cancella il canale v2:

npx @capgo/cli channel delete v2

3. Cancella la branca v1-maintenance:

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

Tip

Questa approccio assicura che gli utenti ricevano solo aggiornamenti compatibili con la loro versione dell'app

Testare sempre gli aggiornamenti attentamente in ogni canale prima della distribuzione

Nota

Puoi cancellare sicuramente il canale v2 in Capgo anche se alcuni utenti hanno ancora l'override del canale. Riceveranno automaticamente gli aggiornamenti dal canale di produzione.

Mantenere Aggiornamenti della Versione 1.x

Per inviare aggiornamenti compatibili con la versione 1.x:

1. Passa al ramo v1-maintenance:

git checkout v1-maintenance

2. Fai le tue modifiche e commita:

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

3. Costruisci e carica nel canale di produzione:

npx @capgo/cli bundle upload --channel production

Tip

Mantieni aggiornata la tua branch v1-maintenance con i patch dei bug compatibili con la versione 1.x, ma non unisci mai le modifiche breaking dalla main

Continua da Breaking Changes

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