Come rilasciare una versione maggiore in capgo

Quando si rilascia una versione maggiore

La gestione delle versioni può essere difficile, di solito si desidera inviare un aggiornamento maggiore quando appare un cambiamento maggiore per gli utenti.

Ma la versioning non è fatta per questo, la versione dell'app store è diversa dalla versione nativa.

La versione nativa è fatta per gestire i cambiamenti di rottura nella code

In IOS, ad esempio, iOS 16 è la store version della Apple, ma la versione code 20A5283p (non sembrano utilizzare SemVer lì)

Ora è chiaro che non li mescoliamo e li utilizziamo per quello per cui sono stati fatti!

Rilascio maggiore

In il tuo Capacitor app, un rilascio maggiore è necessario quando avviene un cambiamento dirompente. Ad esempio, una nuova destinazione IOS (15 a 16), o una nuova versione di Capacitor (3 a 4), o un plugin (1.2 a 2.0) che utilizzi sono stati aggiornati a una versione maggiore.

Questa modifica significa che tutte le attrezzature devono essere allineate per gestire il cambiamento dirompente.

Per questo motivo Capgo segue questo sistema. Quindi se rilasci una versione maggiore, Capgo non lo invierà a un utente che non l'ha installato dal negozio.
Questo comportamento può essere personalizzato. Puoi imparare di più su di esso qui

Versioni

Dove Capgo trova la versione da confrontare

IOS

Verrà utilizzato da Capgo per confrontare la versione JavaScript e trovare l'aggiornamento maggiore

In IOS la variabile è impostata sul tuo progetto qui ios/App/App/Info.plist Sotto la chiaveCFBundleShortVersionString o ios/App/App.xcodeproj/project.pbxproj sotto la chiave MARKETING_VERSION se MARKETING_VERSION era stato impostato nel tuo Info.plist file.

Puoi sovrascrivere questo comportamento impostando la chiave versione nel capacitor.config.json file qui

docs qui

Sarà utilizzato da Capgo per confrontare la versione JavaScript e trovare l'aggiornamento maggiore

in Android, il var è impostato sul tuo progetto qui android/app/build.gradle sotto la chiave defaultConfig.versionName

Puoi sovrascrivere questo comportamento impostando la chiave versione in capacitor.config.json file qui nei documenti

JavaScript

Verrà utilizzato da Capgo per confrontarlo con la versione nativa e trovare l'aggiornamento maggiore

in JavaScript, la variabile viene impostata sul tuo progetto qui package.json sotto la chiave version

Esempio

Il tuo app Ionic è attualmente rilasciata con la versione 1.2.3 con Capacitor 3

Stai facendo l'aggiornamento a capacitor 4.

Devi aggiornare il numero di versione del tuo progetto a 2.2.3, quindi tutti i tuoi pacchetti includono Capgo con la notizia di questo grande cambiamento.

Quando rilasci questa versione su Capgo e su App Store.

Tutti i prossimi live update in Capgo 2.2.4 non saranno mai inviati agli utenti con 1.2.3 versione. Solo con 2.2.3 versione.

Se segui questo modello, non hai più nulla di cui preoccuparti, tutto è gestito bene.

Se non seguo questo

In questo caso, significa che devi inviare la tua nuova app con Capacitor 4 a Apple e Google, ma non a Capgo.

Poi devi aspettare che il 100% dei tuoi utenti, o almeno il 90%, abbia l'applicazione o almeno 90%, ci vorranno mesi, probabilmente.

Mentre in questo periodo non puoi inviare alcuna aggiornamento con Capgo, poiché gli utenti vecchi non possono ricevere la nuova versione. Non hai una possibilità di selezionare solo alcuni utenti per ricevere l'aggiornamento.

Continua da Come rilasciare una versione maggiore in capgo

If stai utilizzando Come rilasciare una versione maggiore in capgo per pianificare il rollback e il controllo delle versioni, connettilo con Rollbacks per i dettagli di implementazione in Rollbacks, Versione Target per i dettagli di implementazione nella Versione Targeting, Comportamento di Aggiornamento per i dettagli di implementazione nella modalità di aggiornamento. bundle per i dettagli di implementazione nel bundle, e Capgo Live Updates per il workflow del prodotto in Capgo Aggiornamenti in tempo reale.