Wenn eine Hauptversion freigegeben wird
Die Versionsverwaltung kann schwierig sein, normalerweise möchten Sie eine Hauptaktualisierung senden, wenn ein wichtiger Änderungsbeitrag für die Benutzer erscheint.
Die Versionsverwaltung ist jedoch nicht dafür gedacht, die App-Store-Version ist anders als die Native-Version.
Die Native-Version ist dafür gedacht, umbruchrelevante Änderungen in der code
In IOS zum Beispiel ist iOS 16 der 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!
Hauptversion
In Ihrer Capacitor App ist eine Hauptversion erforderlich, wenn ein bruchender Änderung passiert. 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 Hauptversion aktualisiert.
Dieser Änderung bedeutet, dass alle Werkzeuge ausgerichtet werden müssen, um die bruchende Änderung zu handhaben.
Deshalb folgt Capgo diesem System.
Wenn Sie also eine Hauptversion veröffentlichen, wird Capgo es nicht an einen Benutzer senden, der es nicht installiert hat, indem er es aus dem Store heruntergeladen hat.
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 Upgrade 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 unter der Schlüssel MARKETING_VERSION Wenn MARKETING_VERSION war in Ihrem Info.plist Datei.
Sie können diese Verhaltensweise überschreiben, indem Sie die Versions-Schlüssel in
capacitor.config.jsonDatei hier
Android
Wird von Capgo verwendet, um die JavaScript-Version zu vergleichen und eine Hauptaktualisierung zu finden
in Android wird die Variable hier auf Ihrem Projekt gesetzt android/app/build.gradle unter der Schlüssel defaultConfig.versionName
Sie können dieses Verhalten überschreiben, indem Sie die Versions-Schlüssel in
capacitor.config.jsonDatei Dokumentation
JavaScript
Wird von Capgo verwendet, um die Native-Version zu vergleichen und eine Hauptaktualisierung zu finden
in JavaScript wird die Variable hier auf Ihrem Projekt gesetzt package.json unter der Schlüssel version
Beispiel
Ihre Ionic-App wird derzeit mit der Version 1.2.3 mit Capacitor 3
Sie führen die Aktualisierung auf capacitor 4 durch.
Sie müssen die Versionsnummer Ihrer App auf 2.2.3, dann enthalten alle Ihre Pakete Capgo mit Hinweis auf diese große Änderung.
Wenn Sie diese Version auf Capgo und in den App Store veröffentlichen.
Alle nächsten live update in Capgo 2.2.4 werden nie an den 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 diesem Muster nicht folge
In diesem Fall bedeutet das, dass Sie Ihr neues App mit Capacitor 4 bei Apple und Google einreichen müssen, aber nicht bei Capgo.
Danach müssen Sie 100% Ihrer Nutzer abwarten, haben die App oder zumindest 90%, das wird Monate dauern, wahrscheinlich.
Während dieser Zeit können Sie keine Update mit Capgo senden, da alte Nutzer die neue Version nicht erhalten können. Sie haben keine Möglichkeit, nur einige Nutzer auszuwählen, die das Update erhalten.
Fortsetzung von Wie Sie eine große Version in capgo veröffentlichen.
Wenn Sie __CAPGO_KEEP_0__ verwenden Wie Sie eine große Version in capgo veröffentlichen Wie Sie eine große Version in __CAPGO_KEEP_0__ veröffentlichen Versionziel für die Implementierungsdetails in Rollbacks, Ziel für die Versionskontrolle für die Implementierungsdetails in der Versionszielsetzung, Ziel für die Versionskontrolle zur Detailbeschreibung in Update-Verhalten, Bundle zur Detailbeschreibung in Bundle und Capgo Live Updates für den Produktworkflow in Capgo Live Updates.
