Modifiche di versione

Questa documentazione spiega come gestire le modifiche di versione nell'applicazione utilizzando canali versionati. Questo 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'app 2.0.0 (nuova versione con modifiche di compatibilità) - 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ò garantisce che possiate sempre inviare aggiornamenti a specifiche fasce di utenti senza dover dipendere dall'assegnazione dinamica del canale.

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

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

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

Suggerimento

Vantaggi di questo approccio:

• Sii sempre in controllo sui utenti che ricevono gli aggiornamenti
• Non è necessario il passaggio dinamico del canale nel tuo app code
• Separazione chiara tra le diverse versioni dell'app
• Flessibilità per inviare aggiornamenti a qualsiasi gruppo di versione specifico

1. Crea Canale per Nuova Versione

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

2. Aggiorna la configurazione Capacitor per la versione 2.0.0

Aggiorna la tua configurazione Capacitor prima di costruire la versione 2.0.0 per la store degli 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 il canale. Per le future versioni principali, impostare sempre un canale specifico come production If you didn’t set a v3, v4ecc.

3. Gestisci rami separati Code

Creare rami separati Git 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

Importante: Non inviare mai pacchetti JavaScript alle vecchie app che aspettano API native code che non hanno. Costruisci sempre gli aggiornamenti dal ramo appropriato:

• ramo di manutenzione v1: Per gli aggiornamenti per le app 1.x (canale di produzione)
• ramo principale: Per gli aggiornamenti per le app 2.x (canale v2)

4. Carica Pacchetti 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 Auto-Assegnazione

# 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 aggiornano) utilizzeranno automaticamente il canale v2 perché è configurato nel pacchetto dell'applicazione.

Nota

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

Scaling to Future Versions

Quando rilascerete la versione 3.0.0 con più modifiche dirompenti:

# 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 → Versione 1.x utenti
• 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):

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

npx @capgo/cli channel delete v2

3. Elimina la branca v1-maintenance:

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

Suggerimento

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 ancora hanno l'override del canale. Riceveranno automaticamente gli aggiornamenti dal canale di produzione.

Aggiornamento 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 committa:

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

3. Costruisci e carica sul canale di produzione:

npx @capgo/cli bundle upload --channel production

Suggerimento

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 da main

Continua da qui: Modifiche breaking

Se stai utilizzando Modifiche di Rilascio 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 workflow del prodotto in Soluzione di Test Beta, e Soluzione di Targeting della Versione per il flusso di lavoro del prodotto nella Soluzione di Targeting della Versione.