Cambiamenti 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

Supponiamo 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 gruppi 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:

• Avere sempre il controllo sui utenti che ricevono gli aggiornamenti
• Non è necessario il passaggio dinamico del canale nella tua 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 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 il canale. Per le future versioni maggiori, impostare sempre un canale specifico come production channel. For future major versions, always set a specific channel like 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

Pubblica 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'app.

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 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 → 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. Elimina defaultChannel dal tuo Capacitor config
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

Nota

Questa approccio garantisce agli utenti solo le notifiche di aggiornamento compatibili con la loro versione dell'app

Testare sempre le notifiche di aggiornamento 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 le notifiche di aggiornamento dal canale di produzione.

Manutenzione delle 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 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 che sono compatibili con la versione 1.x, ma non unisci mai cambiamenti di rottura da main

Continua da qui: Cambiamenti di rottura

Se stai utilizzando Cambiamenti 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 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.