Capgo Semver Tester

Überprüfe die Kompatibilität der Kanalrichtlinie gegenüber der native Baseline, die als version_build gesendet wird

Native Baseline Version

Die native Version, die Capgo als version_build gesendet wird, aus der Konfiguration oder dem native App-Metadaten

Remote Version

Die Bundle-Version, die dem aufgelösten Kanal zugewiesen ist

Anwendungs Kontext

Plattform

Entwicklungsbau

Laufzeit auf Emulator

Kanal-Einstellungen

iOS

Aktualisierungen für iOS-Geräte zulassen

Android

Aktualisierungen für Android-Geräte zulassen

Entwicklungsbau zulassen

Aktualisierungen für Entwicklungsbau zulassen

Emulatoren zulassen

Updates für Emulatoren zulassen

Automatische Downgrade unter Native deaktivieren

Verhindert das Herunterstufen beim Ausführen von Native code

Automatische Updates deaktivieren

Haupt: Blockiert Zielhauptversion größer als version_build. Erlaubt 1.2.3 -> 1.9.0, blockiert 1.2.3 -> 2.0.0.

Eingeben Sie zwei semantische Versionen, um eine Vergleichsliste zu sehen

Was bedeutet "Native Baseline Version"

Die Native Baseline Version ist die native App-Version, die an Capgo als version_build als der Gerät den Update-Server für eine Bundle anfragt. In einer Capacitor-App kann dieser Wert aus CapacitorUpdater.version aus capacitor.config.*. Wenn diese Einstellung nicht package.json vorhanden ist, fällt der Plugin auf die native App-Version von iOS oder Android zurück. Nehmen Sie an, es ist Ihre

Version, es sei denn, Ihre Build kopiert diesen Wert in die Konfiguration oder in native Metadaten ein. Capgo verwendet immer noch version_name um zu wissen, welcher heruntergeladene Bundle derzeit installiert ist. Kanal semver-Politiken wie major, minor, und patch den Remote-Bundle gegen version_build.

Capacitor-Konfiguration

Setzen CapacitorUpdater.version wenn Sie eine explizite Version möchten, die vom App-Client gesendet wird.

Vorteil: leicht, um denselben über iOS- und Android-Builds zu halten.

Nachteil: Stale-Konfiguration kann falsche Versionen melden, wenn Sie vergessen, sie vor einer nativen Veröffentlichung zu aktualisieren.

Native-App-Version

Verwenden Sie die Plattformversion, z.B. iOS CFBundleShortVersionString oder Android versionName.

Pro: entspricht der binären Software, die Benutzer von TestFlight, App Store, Play Store oder interner Testung installiert haben.

Con: Eine Änderung erfordert eine native Build und kann je nach Plattform unterschiedlich sein, wenn sich die Release-Einstellungen verschieben.

Zielgruppenerfassung

Vergleiche es mit Remote-Bundle-Versionen, Kanal-Semver-Regeln oder Upload-Beschränkungen wie --native-version.

Pro: verhindert das Senden von JavaScript, das eine neuere native code benötigt, an alte App-Binärdateien.

Con: Regeln, die zu streng sind, können gültige Updates blockieren, bis der Kanal oder die Bundle-Metadaten angepasst werden.

Für diesen Tester eingeben Sie die native Basislinie, die das Gerät sendet version_build Dann vergleicht sie sich mit der Remote-Bundle-Version, die du Capgo liefern möchtest.

Wieso verwendet Capgo Semantic Versioning?

Semantic Versioning ist die am weitesten verbreitete Versionskonvention in der Softwareentwicklung. Durch die Verwendung von semver stellt Capgo sicher, dass die Live-Updates für deine Capacitor-Apps kompatibel und sicher sind.

Die semver-Konvention ermöglicht es Capgo, genau zu verstehen, welche Änderungen in jedem Update enthalten sind:

Patch-Updates (1.0.0 → 1.0.1): Bugfixes, sicher automatisch anzuwenden
Minor-Updates (1.0.0 → 1.1.0): Neue Funktionen, rückwärts kompatibel
Major-Updates (1.0.0 → 2.0.0): Bruchstellen, erfordern eine native App-Store-Veröffentlichung

Dadurch verhindert Capgo, dass ein inkompatibles Update an deine native code gesendet wird, und schützt deine Benutzer vor Crashes, während sichergestellt wird, dass deine App stabil bleibt.

Flexible Semver Strategien: Hinter der Grundlage der Versionsnummerierung

Während semver streng über seine Kernstruktur ist, können Sie sie für die Bedürfnisse Ihres Teams erweitern, indem Sie Vorabversionsidentifikatoren und Baumetadaten:

🏷️ Build-Metadaten (+) - Die 'ästhetische' Ebene

1.2.0+20240315.142530

Zeitstempel für die Verfolgung von Bereitstellungen

1.2.0+ui.refresh.dark-mode

Beschreibung der UI-Update für das Designteam

1.2.0+build.4729.commit.a1b2c3d

Zahl der CI/CD-Bereitstellung und Git-Commit

Wichtige Hinweise: Wird bei der Versionsvorrangigkeit ignoriert - 1.2.0+anything equals 1.2.0 für Capgo's Update-Logik.

🔧 Vorab-Identifikatoren (-) - Entwicklungskanäle

1.3.0-beta.1

Kanäle für Beta-Testversion

1.3.0-hotfix.payment

Notfall-Fix-Branch

1.3.0-feature.newapi

Kanäle für Feature-Branch-Testversion

Hinweis: Vorabversionen haben einen niedrigeren Vorrang - 1.3.0-beta.1 < 1.3.0

Hybride Ansatz - Best of Beiden Welten

1.3.0-rc.1+ui.redesign.20240315

Freigabekandidat mit UI-Metadaten und Zeitstempel

Real-World Semver-Anwendungsfälle und Teamstrategien

🚀 Startup / Schnelle Entwicklung

0.1.0 - Erste MVP-Freigabe

0.2.0-beta.1 - Neuer Funktionsumfang

0.2.0+ui.v2 - UI-Design-Metadaten

1.0.0 - Produktionsreif

Verwende 0.x.x für die Entwicklung vor 1.0, Metadaten für das Design-Tracking

🏢 Unternehmen / Regulierte

2.1.0 → Quartalsfreigabe

2.1.1+sec.patch.cve2024 → Sicherheitspatch mit Tracking

2.2.0-rc.1+audit.ready → Vorkontrollreleasekandidat

Strict semver mit Compliance-Metadaten

🎮 Gaming- / Kreativ-Apps

1.0.0+season.winter.2024 → Saisonales Inhalt

1.1.0+event.halloween → Ereignis-gesteuerte Funktionen

1.2.0+assets.hd.remaster → Asset-Updates

Kreativ-Metadaten für Inhalts-Tracking

⚡ Hotfix-Strategie

1.2.0 → Aktuelle Produktion

1.2.1-hotfix.payment → Kritischer Fehlerbehebung

1.2.1+urgent.20240315.1430 → Freigegeben mit Timestamp

Vorabversion für die Testung, Metadaten für die Abrechnung der Bereitstellung

🌍 Strategie für mehrere Plattformen

1.3.0+ios.optimized → Optimierungen für iOS

1.3.0+android.material3 → Aktualisierungen für Android

1.3.0+web.pwa.ready → Fähigkeiten für PWA

Selbe Version, plattform-spezifische Metadaten

🔄 Integration von CI/CD

1.4.0-alpha.1+build.123 → Automatisierte Vorabversion

1.4.0+deploy.staging.456 → Bereitstellung in der Staging-Umgebung

1.4.0+prod.final.789 → Bereitstellung in der Produktionsumgebung

Automatisierte Versionsnummer mit Metadaten für die Bereitstellung

💡 Pro-Tipps:

Verwenden Sie die Build-Metadaten (+) für die Verfolgung, Zeitstempel oder kosmetische Informationen, die die Kompatibilität nicht beeinflussen.
Verwenden Sie Vorabversionen (-) für Entwicklungskanäle, die unterschiedliche Aktualisierungsreihenfolgen benötigen.
Combiniert man beide für maximalen Flexibilität: 1.2.0-beta.1+ui.dark.theme.20240315
Denken Sie daran: Capgo respektiert die semver-Vorrangregeln, also planen Sie Ihre Kanalstrategie entsprechend.

Wichtig: Capgo verwendet strikte semantische Versionsierung.

Im Gegensatz zur semver-Implementierung von npm folgt Capgo streng der offizielle SemVer-Spezifikation. npm's node-semver weist bekannte Abweichungen von der Spezifikation auf, was zu unerwartetem Verhalten führen kann.

Zum Beispiel behandelt npm Versionen wie 1.0.0-alpha.1 anders als die Spezifikation vorsieht. Siehe unsere berichtete Issue und versuchte Lösung die nie integriert wurde.

Gültige semantische Versionen

1.0.0 ✓ Standardveröffentlichung

2.1.3-alpha ✓ Vorkommerziale Version

1.0.0-beta.1 ✓ Vorkommerziale Version mit Zahl

1.0.0+build.1 ✓ Build-Metadaten

1.0.0-rc.1+build.1 ✓ Vollständige Version

Ungültige semantische Versionen

v1.0.0 ✗ Führende 'v' nicht erlaubt

1.0 ✗ Patchversion fehlt

1.0.0.0 ✗ Zu viele Versionsteile

1.0.0- ✗ Leere Vorkommerziale Version

1.0.0+ ✗ Leere Build-Metadaten

Capgo Aktualisierungsverhalten

✓ Kleiner Strategie ermöglicht Patch-Änderungen in derselben major.minor Zeile, zum Beispiel 1.0.0 -> 1.0.1

✓ Patch-Strategie blockiert 1.0.0 -> 1.0.1. Sie ermöglicht nur Suffix-Änderungen wie 1.0.0-beta.1 -> 1.0.0-beta.2.

✗ Großstrategie blockiert Zielbündel mit einem höheren Major als die native Basis, zum Beispiel 1.0.0 -> 2.0.0

⚠ Rückgängig-Machungsschutz verwendet volle semver Vorrang, also ist stabiles 1.0.0 neuer als 1.0.0-beta.2

Diese Werkzeug folgt der offiziellen Semantic Versioning-Spezifikation anders als npm's Implementierung.