Quando rilasci una versione major
Gestire il versioning può essere difficile; di solito si vuole inviare un aggiornamento major quando avviene un cambiamento importante per gli utenti.
Ma il versioning non è nato per questo: la versione dell'app store è diversa dalla versione Native.
La versione Native serve a gestire i breaking change nel code
Su iOS, ad esempio, iOS 16 è la store version di Apple, ma la versione code è 20A5283p (non sembrano usare SemVer lì)
Ora è chiaro: non dobbiamo mescolarle e usarle per ciò per cui sono nate!
Rilascio di una major version
Nella tua app Capacitor, una major release è necessaria quando avviene un breaking change. Ad esempio, un nuovo target iOS (da 15 a 16), una nuova versione di Capacitor (da 3 a 4), o un plugin (da 1.2 a 2.0) che usi sono stati aggiornati a una major version.
Questo cambiamento significa che tutti i tool devono essere allineati per gestire il breaking change.
Ecco perché Capgo segue questo sistema.
Quindi, se rilasci una major version, Capgo non la invierà a un utente che non l'ha installata dallo store.
Questo comportamento può essere personalizzato. Puoi saperne di più qui
Versioni
Dove Capgo trova la versione da confrontare
iOS
Sarà usato da Capgo per confrontare la versione JavaScript e trovare l'upgrade Major
In iOS la variabile è impostata qui nel tuo progetto ios/App/App/Info.plist sotto la chiaveCFBundleShortVersionString o ios/App/App.xcodeproj/project.pbxproj sotto la chiave MARKETING_VERSION se MARKETING_VERSION era impostata nel tuo Info.plist file.
Puoi sovrascrivere questo comportamento impostando la chiave version in
capacitor.config.jsonfile docs qui
Android
Capgo lo userà per confrontarlo con la versione JavaScript e trovare il major upgrade
in Android, la var è impostata qui nel tuo progetto android/app/build.gradle sotto la chiave defaultConfig.versionName
Puoi sovrascrivere questo comportamento impostando la chiave version in
capacitor.config.jsonfile docs qui
JavaScript
Capgo lo userà per confrontarlo con la versione Native e trovare il major upgrade
in JavaScript, la var è impostata qui nel tuo progetto package.json sotto la chiave version
Esempio
La tua app Ionic è attualmente rilasciata con la versione 1.2.3 con Capacitor 3
Stai effettuando l'upgrade a capacitor 4.
Devi aggiornare il tuo numero di versione a 2.2.3, quindi tutti i tuoi pacchetti includeranno Capgo segnalando questo grande cambiamento.
Quando rilascerai questa versione su Capgo e sull'App Store.
Tutti i successivi live update in Capgo 2.2.4 non verranno mai inviati all'utente con la 1.2.3 versione. Solo con la 2.2.3 versione.
Se segui questo pattern, non dovrai più preoccuparti: è tutto gestito correttamente.
Se non seguissi questo approccio
In questo caso, dovresti inviare la nuova versione dell'app con Capacitor 4 ad Apple e Google, ma non tramite Capgo.
Poi dovrai aspettare che il 100% dei tuoi utenti, o almeno il 90%, abbia l'app aggiornata; ci vorranno probabilmente mesi.
Nel frattempo, non potrai inviare alcun aggiornamento con Capgo, poiché gli utenti con la vecchia versione non potrebbero riceverlo. Non avresti modo di selezionare solo alcuni utenti per l'aggiornamento.
Continua da: Come rilasciare una major version in capgo
Se stai usando Come rilasciare una versione major in capgo per pianificare rollback e version control, connettilo a Rollback per i dettagli di implementazione nei Rollback, Targeting delle versioni per i dettagli di implementazione nel Version Targeting, Comportamento degli aggiornamenti per i dettagli di implementazione nell'Update Behavior, bundle per i dettagli di implementazione nel bundle, e Live Updates di Capgo per il workflow del prodotto in Capgo Live Updates.
