When rilasciando una versione maggiore
La versioning può essere difficile da gestire, di solito desideri inviare un aggiornamento maggiore quando una modifica maggiore appare 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 il cambiamento di rottura nel code
In IOS, ad esempio, iOS 16 è il store version di Apple, ma la versione code è 20A5283p (non sembrano utilizzare SemVer lì)
Ora è chiaro che non li mescoliamo e li utilizziamo per ciò per cui sono stati fatti!
Rilascio maggiore
Nella tua Capacitor app, un rilascio maggiore è necessario quando avviene un cambiamento di rottura. Ad esempio, un nuovo target 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.
Questo cambiamento significa che tutte le attrezzature devono essere allineate per gestire il cambiamento di rottura.
Quello è il motivo per cui Capgo segue questo sistema.
Quindi se rilasciate una versione maggiore, Capgo non la invierà a un utente che non l'ha installata 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 confrontarlo con la versione JavaScript e trovare l'aggiornamento maggiore
In iOS la variabile viene impostata nel 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 confrontare 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 nel
capacitor.config.jsonfile documentazione qui
JavaScript
Verrà utilizzato da Capgo per confrontare con la versione Nativa e trovare l'aggiornamento Maggiore
in JavaScript, la variabile è 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.
Hai bisogno di aggiornare il numero di versione a 2.2.3, quindi tutti i tuoi pacchetti includono Capgo con notifica di questo grande cambiamento.
Quando rilasci questa versione su Capgo e l'App Store.
Tutti i prossimi aggiornamenti live in Capgo 2.2.4 non verrà mai inviato all'utente con 1.2.3 versione. Solo con 2.2.3 versione.
Se segui questo modello, non dovrai preoccuparti più, tutto è gestito correttamente.
Se non seguo questo
In questo caso, significa che dovrai inviare la tua nuova app con Capacitor 4 a Apple e Google, ma non a Capgo.
Poi dovrai attendere che il 100% dei tuoi utenti, abbia l'applicazione o almeno il 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
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 di Riferimento per i dettagli di implementazione in Versione di Riferimento, Comportamento dell'Aggiornamento per i dettagli di implementazione in Comportamento dell'Aggiornamento, pacchetto per i dettagli di implementazione in pacchetto, e Capgo Aggiornamenti in Tempo Reale per il flusso di lavoro del prodotto in Capgo Aggiornamenti in Tempo Reale.
