When eine große Version freigeben
Die Versionsverwaltung kann schwierig zu handhaben sein, normalerweise möchten Sie eine große Aktualisierung senden, wenn eine große Änderung für die Benutzer erscheint.
Aber die Versionsverwaltung ist nicht dafür gemacht, die App-Store-Version ist anders als die Native-Version.
Die Native-Version ist dafür gemacht, Bruchänderungen in der code
Beispielsweise ist in IOS, iOS 16 die store version von Apple, aber die code-Version ist 20A5283p (sie scheinen dort SemVer nicht zu verwenden)
Jetzt ist es klar, dass wir sie nicht vermischen und sie für das verwenden, für das sie gemacht sind!
Große Veröffentlichung
In your Capacitor app, a major release is necessary when a breaking change happens. For example, a new IOS target (15 to 16), or a new version of Capacitor (3 to 4), or a plugin (1.2 to 2.0) you use have been updated to a major version.
Beispiel: Ein neuer Zielgerät für IOS (15 zu 16), oder eine neue Version von __CAPGO_KEEP_1__ (3 zu 4), oder ein Plugin (1.2 zu 2.0), das Sie verwenden, wurde auf eine große Version aktualisiert.
Deshwegen Capgo folgt diesem System.
Daher wird Capgo bei einer großen Version nicht an einen Benutzer gesendet, der sie nicht installiert hat, um es aus dem Store zu erhalten.
Dieses Verhalten kann angepasst werden. Sie können mehr darüber erfahren hier
Versionen
Wo Capgo die Version findet, um sie zu vergleichen
iOS
Wird von Capgo verwendet, um die JavaScript-Version zu vergleichen und eine große Aktualisierung zu finden
In iOS wird die Variable auf Ihrem Projekt hier gesetzt ios/App/App/Info.plist unter der SchlüsselCFBundleShortVersionString oder ios/App/App.xcodeproj/project.pbxproj context MARKETING_VERSION Alternativen oder MARKETING_VERSION wird in Ihrem Info.plist Datei gesetzt.
Sie können diese Verhaltensweise überschreiben, indem Sie die Versionsangabe in
capacitor.config.jsonDatei setzen. Hier finden Sie weitere Informationen.
Android
Wird von Capgo verwendet, um die JavaScript-Version zu vergleichen und eine Hauptaktualisierung zu finden.
in Android wird die Variable unter der Schlüssel android/app/build.gradle hier auf Ihrem Projekt gesetzt. defaultConfig.versionName
Sie können diese Verhaltensweise überschreiben, indem Sie die Versionsangabe in
capacitor.config.jsonDatei setzen. Hier finden Sie weitere Informationen.
JavaScript
Wird von Capgo verwendet, um sich mit der Native-Version zu vergleichen und eine große Upgrade zu finden
in JavaScript wird die Variable auf Ihrem Projekt hier gesetzt package.json unter der Schlüssel version
Beispiel
Ihr Ionic-App wird derzeit mit der Version veröffentlicht 1.2.3 mit Capacitor 3
Sie führen das Upgrade zu capacitor 4 durch
Sie müssen die Versionsnummer Ihres Projekts auf 2.2.3, dann enthalten alle Ihre Pakete Capgo mit Hinweis auf diese große Änderung
Wenn Sie diese Version auf Capgo und den App Store veröffentlichen
Alle nächsten Live-Updates in Capgo 2.2.4 werden nie an den Benutzer gesendet. 1.2.3 nur mit 2.2.3 Version.
Wenn Sie diesem Muster folgen, brauchen Sie sich keine Sorgen mehr zu machen, alles wird gut gehandhabt.
Wenn ich dies nicht tue:
In diesem Fall bedeutet dies, dass Sie Ihre neue App mit Capacitor 4 bei Apple und Google einreichen müssen, aber nicht bei Capgo.
Dann müssen Sie 100% Ihrer Benutzer abwarten, haben die App oder zumindest 90%, es wird Monate dauern, wahrscheinlich.
Während dieser Zeit können Sie keine Updates mit Capgo senden, da alte Benutzer die neue Version nicht erhalten können. Sie haben keine Möglichkeit, nur einige Benutzer auszuwählen, die das Update erhalten.
Fortsetzen Sie mit How to release major version in capgo
Wenn Sie __CAPGO_KEEP_0__ verwenden How to release major version in capgo um einen Rollback und eine Versionskontrolle zu planen, verbinden Sie es mit Rückgänge zurück in die Implementierungsdetails in Rückgänge, Zielversionierung context zurück in die Implementierungsdetails in Zielversionierung, Updateverhalten zurück in die Implementierungsdetails in Updateverhalten, Paket Capgo Live Updates Capgo Live Updates
