Zum Hauptinhalt springen
Anleitung

Wie man eine große Version in capgo veröffentlicht

Erfassen Sie, wie und wann es notwendig ist, eine große Version für Ihre App ohne die App Ihres Benutzers zu stören

Martin Donadieu

Martin Donadieu

Inhaltsmarketer

Wie man eine große Version in capgo veröffentlicht

Wenn Sie eine große Version veröffentlichen

Die Versionsverwaltung kann schwierig sein, Sie möchten normalerweise 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, um Bruchänderungen in der code

In iOS zum Beispiel ist iOS 16 das store version von Apple, aber die code-Version ist 20A5283p (sie scheinen dort keine SemVer 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 Ihrer Capacitor-App ist eine große Veröffentlichung erforderlich, wenn ein bruchender Änderung passiert. Beispiel: Ein neuer Zielplattform (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 eingestellt werden müssen, dass sie die bruchende Änderung handhaben können.

Deswegen folgt Capgo diesem System. Also wenn Sie eine große Version veröffentlichen, wird Capgo sie nicht an einen Benutzer senden, der sie nicht installiert hat, indem er sie 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 sie mit der 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 oder MARKETING_VERSION unter der Schlüssel MARKETING_VERSION wenn Info.plist wurde in Ihrem

Datei gesetzt capacitor.config.json Sie können diese Verhaltensweise überschreiben, indem Sie die Versionsschlüssel in der Dokumentation hier

Android

Wird von Capgo verwendet, um die JavaScript-Version zu vergleichen und eine Hauptaktualisierung 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 dieses Verhalten überschreiben, indem Sie die Versionsnummer im capacitor.config.json Datei Dokumentation hier

JavaScript

Wird von Capgo verwendet, um die Native-Version zu vergleichen und eine Hauptaktualisierung zu finden

In JavaScript wird die Variable auf Ihrem Projekt hier gesetzt package.json unter der Schlüssel version

Beispiel

Ihre 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 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 den App Store veröffentlichen.

Alle nächsten Live-Updates in Capgo 2.2.4 werden niemals 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.

If Sie diese Anweisungen nicht befolgen

In diesem Fall bedeutet das, dass Sie Ihr neues App mit Capacitor 4 bei Apple und Google einreichen müssen, aber nicht bei Capgo.

Sie müssen dann 100% Ihrer Benutzer abwarten, haben die App 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.

Fortsetzen Sie mit der Anleitung zur Veröffentlichung einer großen Version in capgo

Wenn Sie eine dieser Anwendungen verwenden Anleitung zur Veröffentlichung einer großen Version in capgo um eine Rückschaltung und Versionskontrolle zu planen, verbinden Sie sie mit Rückschaltungen zur Implementierungsdetail in Rückschaltungen, Zielversionierung zur Implementierungsdetail in Zielversionierung, Updateverhalten zur Detailbeschreibung in Updateverhalten, Bundle zur Detailbeschreibung in Bundle und Capgo Live Updates zur Produktworkflow in Capgo Live Updates.

Live-Updates für Capacitor-Apps

When a web-layer bug is live, ship the fix through Capgo instead of waiting days for app store approval. Users get the update in the background while native changes stay in the normal review path.

Wenn ein Web-Schicht-Bug live ist, versenden Sie die Reparatur über __CAPGO_KEEP_0__ anstatt Tage auf die Genehmigung der App-Store-Abteilung zu warten. Die Benutzer erhalten die Aktualisierung im Hintergrund, während native Änderungen im normalen Review-Prozess bleiben.

Menschliche Unterstützung von Martin. Kontext: Homepage-Marketing-Text. Rolle: Website-Text. Gesehen in: Komponente HumanSupport.astro, Komponente pricing/Plans.astro. Nachrichtenschlüssel `home_hero_human_support` (Home Hero Human Support).

Neueste von unserem Blog

Capgo bietet Ihnen die besten Einblicke, die Sie benötigen, um eine wirklich professionelle mobile App zu erstellen.