Beim Release einer Major-Version
Versioning kann schwierig zu handhaben sein; meistens will man ein Major-Update senden, wenn für die User eine größere Änderung auftritt.
Aber Versionierung ist nicht dafür gedacht, da die App Store Version von der Native Build Version abweicht.
Die Native-Version dient dazu, Breaking Changes in der code
Bei iOS zum Beispiel ist iOS 16 die store version von Apple, aber die code Version ist 20A5283p (dort scheint man kein SemVer zu nutzen)
Jetzt ist klar: Wir mischen sie nicht, sondern nutzen sie genau für das, wofür sie gedacht sind!
Major Release
In deiner Capacitor App ist ein Major Release nötig, wenn es Breaking Changes gibt. Zum Beispiel ein neues iOS-Target (15 auf 16), eine neue Version von Capacitor (3 auf 4) oder ein Plugin (1.2 auf 2.0), das auf eine Major Version aktualisiert wurde.
Diese Änderung bedeutet, dass das gesamte Tooling angepasst werden muss, um den Breaking Change zu handhaben.
Deshalb folgt Capgo diesem System.
Wenn du also ein Major Release veröffentlichst, wird Capgo dieses nicht an User senden, die die entsprechende Version nicht aus dem Store installiert haben.
Dieses Verhalten lässt sich anpassen. Mehr dazu erfährst du hier hier
Versionen
Wo Capgo die zu vergleichende Version findet
iOS
Wird von Capgo genutzt, um die JavaScript-Version zu vergleichen und Major-Upgrades zu finden
In iOS wird die Variable in deinem Projekt hier gesetzt ios/App/App/Info.plist unter dem KeyCFBundleShortVersionString oder ios/App/App.xcodeproj/project.pbxproj unter dem Key MARKETING_VERSION falls MARKETING_VERSION wurde in deinem Info.plist Datei.
Du kannst dieses Verhalten überschreiben, indem du den Version-Key in der
capacitor.config.jsonDatei Docs hier
Android
Capgo nutzt dies zum Vergleich mit der JavaScript-Version, um Major-Upgrades zu finden
In Android wird die Variable hier in deinem Projekt gesetzt android/app/build.gradle unter dem Key defaultConfig.versionName
Du kannst dieses Verhalten überschreiben, indem du den Version-Key in der
capacitor.config.jsonDatei Docs hier
JavaScript
Capgo nutzt dies zum Vergleich mit der Native-Version, um Major-Upgrades zu finden
In JavaScript wird die Variable hier in deinem Projekt gesetzt package.json unter dem Key version
Beispiel
Deine Ionic App ist aktuell auf Version 1.2.3 mit Capacitor 3
Du führst das Upgrade auf capacitor 4 durch.
Du musst deine Versionsnummer auf 2.2.3anpassen, damit alle Pakete Capgo mit dieser Änderung erkennen.
Wenn du diese Version für Capgo und den App Store veröffentlichst.
Alle folgenden live update in Capgo 2.2.4 werden niemals an User mit der 1.2.3 Version gesendet. Nur mit 2.2.3 Version.
Wenn du dieses Muster befolgst, musst du dir keine Sorgen machen, alles ist abgedeckt.
Wenn ich das nicht befolge
Das bedeutet, dass du deine neue App mit Capacitor 4 an Apple und Google senden musst, aber nicht über Capgo.
Dann musst du warten, bis 90 % bis 100 % deiner Nutzer die App installiert haben – das wird wahrscheinlich Monate dauern.
In dieser Zeit kannst du keine Updates mit Capgo senden, da alte Nutzer die neue Version nicht erhalten können. Du hast keine Möglichkeit, gezielt nur bestimmte Nutzer für das Update auszuwählen.
Weiterlesen: So veröffentlichst du eine Major-Version in capgo
Wenn du es nutzt So veröffentlichst du eine Major-Version in capgo um Rollbacks und die Versionskontrolle zu planen, verbinde es mit Rollbacks für die Implementierungsdetails in Rollbacks, Version-Targeting für die Implementierungsdetails in Version Targeting, Update-Verhalten für die Implementierungsdetails im Update-Verhalten, Bundle für die Implementierungsdetails im Bundle und Capgo Live Updates für den Produkt-Workflow in Capgo Live Updates.
