Wenn ein großer Versionsstand veröffentlicht wird
Die Versionsverwaltung kann schwierig sein, normalerweise möchten Sie eine große Aktualisierung 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, umbruchartige Änderungen im code
In IOS zum Beispiel ist iOS 16 der 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, wofür sie gemacht sind!
Große Veröffentlichung
In Ihrer Capacitor App ist eine große Veröffentlichung erforderlich, wenn ein umbruchartiger Änderungsbedarf auftritt. 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 ausgerichtet werden müssen, um den umbruchartigen Änderungsbedarf zu handhaben.
Das ist der Grund, warum Capgo dieses System befolgt.
Daher wird Capgo bei einer großen Version nicht an einen Benutzer gesendet, der sie nicht installiert hat, wenn sie 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 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 unter der Schlüssel MARKETING_VERSION wenn MARKETING_VERSION wurde in Ihrem Info.plist Datei gesetzt.
Sie können dieses Verhalten durch das Setzen der version-Schlüssel in
capacitor.config.jsonDatei Dokumentation hier
Android
Wird von Capgo verwendet, um mit der JavaScript-Version zu vergleichen und eine Hauptaktualisierung zu finden
in Android wird die Variable unter der Schlüssel android/app/build.gradle Dokumentation hier defaultConfig.versionName
Sie können dieses Verhalten durch das Setzen der version-Schlüssel in
capacitor.config.jsonDatei Dokumentation hier
JavaScript
Wird von Capgo verwendet, um mit der Native-Version zu vergleichen und eine große Aktualisierung 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 veröffentlicht 1.2.3 mit Capacitor 3
Sie führen die Aktualisierung zu capacitor 4 durch
Sie müssen die Versionsnummer 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 Wird nie an den Benutzer mit 1.2.3 Version. 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 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 Update 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 von Wie man eine Hauptversion in capgo veröffentlicht
Wenn Sie Wie man eine Hauptversion in capgo veröffentlicht um einen Rollback und Versionskontrolle zu planen, verbinden Sie es mit Rückgängigmachung für die Implementierungsdetails in Rückgängigmachung, Zielsprachversion für die Implementierungsdetails in Zielsprachversion, Aktualisierungsverhalten für die Implementierungsdetails in Aktualisierungsverhalten, Bündel für die Implementierungsdetails in Bündel, und Capgo Live Updates für den Produktworkflow in Capgo Live Updates.
