Quando si rilascia una versione maggiore
La versioning può essere difficile da gestire, di solito si desidera inviare un aggiornamento maggiore quando compare 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 rotta nella code
In IOS, ad esempio, iOS 16 è il store version di Apple, ma la versione code è 20A5283p (non sembra che utilizzino SemVer lì)
Now è chiaro che non li mescoliamo e li utilizziamo per quello per cui sono stati creati!
Rilascio maggiore
In tuo app Capacitor, è necessario un rilascio maggiore quando accade 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 è stato aggiornato 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 è stato impostato nel tuo Info.plist file.
Puoi sovrascrivere questo comportamento impostando la chiave versione nel
capacitor.config.jsonfile documentazione qui
Android
Verrà utilizzato da Capgo per confrontarlo con la versione JavaScript e trovare l'aggiornamento maggiore
in Android, la variabile è impostata nel tuo progetto qui android/app/build.gradle sotto la chiave defaultConfig.versionName
Puoi sovrascrivere questo comportamento impostando la chiave versione in
capacitor.config.jsonfile qui i documenti
JavaScript
Verrà utilizzato da Capgo per confrontarlo con la versione Nativa e trovare l'aggiornamento Maggiore
in JavaScript, la variabile è impostata nel tuo progetto qui package.json sotto la chiave version
Esempio
La tua app Ionic è attualmente rilasciata con la versione 1.2.3 con Capacitor 3
Stai facendo l'aggiornamento a capacitor 4.
È necessario aggiornare il numero di versione a 2.2.3. Tutti i pacchetti includono Capgo con un grande avviso di questo cambiamento.
Quando rilasciate questa versione su Capgo e su App Store.
Tutti gli aggiornamenti live successivi in Capgo 2.2.4 non saranno mai inviati agli utenti con 1.2.3 versione. Solo con 2.2.3 versione.
Se seguite questo modello, non dovete preoccuparvi più, tutto è gestito correttamente.
Se non seguo questo
In questo caso, ciò significa che dovete inviare la nuova app con Capacitor 4 a Apple e Google, ma non a Capgo.
Poi dovete attendere che il 100% dei vostri utenti, o almeno il 90%, abbia l'applicazione o almeno 90%, ciò richiederà mesi, probabilmente.
Mentre in questo periodo non potete inviare alcun aggiornamento con Capgo, poiché gli utenti vecchi non possono ricevere la nuova versione. Non avete un modo per selezionare solo alcuni utenti per ricevere l'aggiornamento.
Continua da Come rilasciare una versione maggiore in capgo
Se stai utilizzando Come rilasciare una versione maggiore in capgo per pianificare il rollback e il controllo delle versioni, connettilo con Rollback per i dettagli di implementazione in Rollback, Versione Target per i dettagli di implementazione in Versione Target, Comportamento Aggiornamento per i dettagli di implementazione in Comportamento Aggiornamento, pacchetto per i dettagli di implementazione in pacchetto, e Aggiornamenti in tempo reale Capgo per il workflow del prodotto in Aggiornamenti in tempo reale Capgo.
