Wenn man eine Hauptversion veröffentlicht
Die Versionsverwaltung kann schwierig sein, normalerweise möchte man eine Hauptaktualisierung senden, wenn ein großer Änderungsbedarf 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, umbruchreiche Änderungen im code
Beispielsweise ist iOS 16 die store version von Apple, aber die code-Version ist 20A5283p (sie scheinen dort keine SemVer zu verwenden)
Jetzt ist klar, dass wir sie nicht vermischen und sie für das verwenden, für das sie gemacht sind!
Große Veröffentlichung
In Ihrem Capacitor-App ist eine große Veröffentlichung erforderlich, wenn ein bruchender Änderung vorkommt. Beispiel: Ein neuer IOS-Ziel (15 zu 16), oder eine neue Version von Capacitor (3 zu 4), oder ein Plugin (1.2 zu 2.0), das Sie verwenden, wurde auf eine große Version aktualisiert.
Diese Änderung bedeutet, dass alle Werkzeuge so konfiguriert werden müssen, dass sie die bruchende Änderung handhaben können.
Deswegen folgt Capgo diesem System.
Daher wird Capgo bei einer großen Version nicht an einen Benutzer gesendet, der diese nicht installiert hat, um es vom 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 sie mit der JavaScript-Version zu vergleichen und eine große Upgrade zu finden
In IOS wird die Variable hier auf Ihrem Projekt gesetzt ios/App/App/Info.plist unter der SchlüsselCFBundleShortVersionString oder ios/App/App.xcodeproj/project.pbxproj unter der Schlüssel MARKETING_VERSION wenn MARKETING_VERSION wurde in Ihrem Info.plist Datei gesetzt.
Sie können diese Verhaltensweise überschreiben, indem Sie den Schlüssel version in
capacitor.config.jsonDatei setzen Dokumentation hier
Android
Wird von Capgo verwendet, um sich mit der JavaScript-Version zu vergleichen und eine große Aktualisierung zu finden
in Android wird die Variable auf Ihrem Projekt hier gesetzt android/app/build.gradle unter der Schlüssel defaultConfig.versionName
Sie können diese Verhaltensweise überschreiben, indem Sie die Versionsnummer unter dem Schlüssel in
capacitor.config.jsonDatei Dokumentation hier
JavaScript
Wird von Capgo verwendet, um sich mit der Native-Version zu vergleichen und eine Hauptaktualisierung zu finden
in JavaScript wird die var auf Ihrem Projekt hier gesetzt package.json unter der Schlüssel version
Beispiel
Ihr Ionic-App wird derzeit mit der Version 1.2.3 mit Capacitor 3
Sie führen die Aktualisierung zu capacitor 4 durch.
You müssen Ihre Versionsnummer auf 2.2.3, dann werden alle Ihre Pakete mit Capgo mit dieser großen Änderung versehen.
Wenn Sie diese Version auf Capgo und in den App Store veröffentlichen.
Alle nächsten Live-Updates in Capgo 2.2.4 werden niemals an Benutzer mit 1.2.3 Version gesendet. 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 das, dass Sie Ihre neue App mit Capacitor 4 bei Apple und Google einreichen müssen, aber nicht bei Capgo.
Dann müssen Sie warten, bis 100% Ihrer Benutzer die App haben oder zumindest 90%, das 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.
Bleiben Sie bei der Veröffentlichung einer großen Version in capgo
Wenn Sie Bleiben Sie bei der Veröffentlichung einer großen Version in capgo um einen Rollover und eine Versionskontrolle zu planen, verbinden Sie es mit Rollover für die Implementierungsdetails in Rollover, Zielversion für die Implementierungsdetails in Zielversion, Aktualisierungsverhalten für die Implementierungsdetails in Aktualisierungsverhalten, paketieren für die Implementierungsdetails in paketieren, und Capgo Live Updates für den Produktworkflow in Capgo Live Updates.
