Aggiornamenti di Breaking Changes

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

Scenario di esempio

Diciamo di avere:

• L'App versione 1.2.3 (versione vecchia) - utilizza il canale di produzione
• L'App versione 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 il defaultChannel per le versioni maggiori

Approccio consigliato: Definisci un defaultChannel per ogni versione maggiore. Ciò assicura di poter 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'

Consigli

Vantaggi di questo approccio:

• Sempre avere il controllo sui utenti che ricevono gli aggiornamenti
• Non è necessario il passaggio dinamico del canale nella tua app __CAPGO_KEEP_0__ needed in your app code
• tra le diverse versioni dell'app Flexibilità
• per inviare aggiornamenti a qualsiasi gruppo di versione specifico 1. Crea un canale per la nuova versione

2. Aggiorna il canale

# 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 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 production canale. Per le future versioni maggiori, impostare sempre un canale specifico come v3, v4, ecc.

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

Importante: Non spingere mai i pacchetti JavaScript verso le vecchie app che aspettano API native code che non hanno. Costruisci sempre gli aggiornamenti dal ramo appropriato:

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

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 auto

# 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 nella store delle app. Tutti gli utenti che scaricano questa versione (siano nuovi utenti o utenti esistenti che stanno aggiornando) utilizzeranno automaticamente il canale v2 perché è configurato nel bundle dell'applicazione.

Nota

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

Scaling to Future Versions

Quando rilascerai la versione 3.0.0 con ulteriori 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 puoi 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):

1. Elimina defaultChannel rimuovi dal tuo Capacitor config
2. Cancella 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 garantisce che gli utenti ricevano solo aggiornamenti compatibili con la loro versione dell'app

Testa sempre gli aggiornamenti attentamente in ogni canale prima della distribuzione

Nota

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

Mantenimento Aggiornamenti della Versione 1.x

Per inviare aggiornamenti compatibili con la versione 1.x:

1. Passa alla branca di manutenzione v1:

git checkout v1-maintenance

2. Fai le tue modifiche e commit:

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

3. Compila e carica sul canale di produzione:

npx @capgo/cli bundle upload --channel production

Consiglio

Mantieni aggiornata la tua branch v1-maintenance con le correzioni di bug compatibili con la versione 1.x, ma non unire mai le modifiche dirottanti da main

Continua da Breaking Changes

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