__CAPGO_KEEP_0__ Live-Update - __CAPGO_KEEP_1__ Cloud
Capgo logo

Capgo Semver-Tester

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

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

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

Zwei semantische Versionen eingeben, um Vergleich zu sehen

Was "Native Baseline Version" bedeutet

Die Native Baseline Version ist die native App-Version, die Capgo als version_build wenn das Gerät den Update-Server um einen Bundle bittet. In einer Capacitor-App kann dieser Wert aus CapacitorUpdater.version kommen. Wenn diese Einstellung nicht capacitor.config.* vorhanden ist, fällt der Plugin auf die native App-Version von iOS oder Android zurück. Nehmen Sie nicht an, dass es Ihre package.json Version ist, es sei denn, Ihre Build kopiert diesen Wert in die Konfiguration oder in native Metadaten.

Capgo verwendet immer noch version_name um zu wissen, welches heruntergeladene Bundle derzeit installiert ist. major, minor, und patch den Remote-Bundle gegen version_build.

Capacitor Konfiguration

Setzen CapacitorUpdater.version wenn Sie eine explizite Version von der App erhalten möchten.

Vorteile: es ist einfach, dasselbe über iOS- und Android-Builds zu halten.

Nachteile: Ein veraltetes Konfiguration kann falsche Versionen anzeigen, wenn Sie vergessen, es vor einer nativen Veröffentlichung zu aktualisieren.

Natives App-Version

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

Vorteile: entspricht dem Binärcode, den Benutzer aus TestFlight, App Store, Play Store oder interner Testung installiert haben.

Nachteile: Änderungen erfordern eine native Build und können je nach Plattform unterschiedlich sein, wenn sich die Release-Einstellungen verschieben.

Zielgruppen für Bundles

Vergleicht es mit Remote-Bundle-Versionen, Channel-semver-Regeln oder Metadaten-Upload-Beschränkungen wie --min-update-versionDer Channel muss --disable-auto-update metadata.

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

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

Für diesen Tester, geben Sie die native Basislinie ein, die das Gerät sendet als version_buildDann vergleichen Sie es mit der Remote-Bundle-Version, die Sie Capgo liefern möchten.

Weshalb Capgo Semantic Versioning verwendet

Semantic Versioning ist die am weitesten verbreitete Versionsstandard in der Softwareentwicklung. Durch die Verwendung von semver stellt Capgo sicher, dass Kompatibilität und Sicherheit gewährleistet sind, wenn live Updates an Ihre Capacitor-Apps geliefert werden.

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

  • Patch-Updates (1.0.0 → 1.0.1): Bug-Fixes, sicher zum automatischen Anwenden
  • Minor-Updates (1.0.0 → 1.1.0): Neue Funktionen, rückwärts kompatibel
  • Major-Updates (1.0.0 → 2.0.0): Bruchstellen-Änderungen, erfordern native App-Store-Veröffentlichung

Dies verhindert, dass Capgo jemals einen inkompatiblen Update an Ihr natives code sendet, schützt Ihre Benutzer vor Abstürzen und stellt sicher, dass Ihre App stabil bleibt.

Flexible Semver-Strategien: Jenseits der grundlegenden Versionsierung

Während semver streng über sein Kernformat ist, können Sie es für die Bedürfnisse Ihres Teams erweitern, indem Sie Vorabversionen identifizieren und Baumetadaten:

🏷️ Build-Metadaten (+) - Die "ästhetische" Schicht

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 den Design-Team
1.2.0+build.4729.commit.a1b2c3d
CI/CD-Buildnummer und Git-Commit

Wichtig: Die Build-Metadaten werden bei der Versionsvorrangigkeit ignoriert - 1.2.0+anything entspricht 1.2.0 für Capgo's Update-Logik.

🔧 Vorabversionen (-) - Entwicklungskanäle

1.3.0-beta.1
Kanäle für Beta-Testzwecke
1.3.0-hotfix.payment
Branch für dringende Reparaturen
1.3.0-feature.newapi
Branch für Funktionstests

Wenn Sie diese Seite verwenden, stimmen Sie unserer Datenschutzrichtlinie zu. Vorabversionen haben eine niedrigere Priorität - 1.3.0-beta.1 < 1.3.0

🎯 Hybrid-Ansatz - Das Beste aus beiden Welten

1.3.0-rc.1+ui.redesign.20240315
Freigabekandidat mit UI-Metadaten und Zeitstempel

Real-Weltliche Semver-Anwendungsfälle & Teamstrategien

🚀 Startup / Schnelle Entwicklung

0.1.0 - Erste MVP-Version
0.2.0-beta.1 - Neuer Funktionsausbau
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

🏢 Enterprise / Regulierte

2.1.0 → Quartalsrelease
2.1.1+sec.patch.cve2024 → Sicherheitspatch mit Tracking
2.2.0-rc.1+audit.ready → Vorentscheidungsreleasekandidat

Strict semver mit Compliance-Metadaten

🎮 Gaming- / Kreativ-Apps

1.0.0+season.winter.2024 → Saisonales Inhalt
1.1.0+event.halloween → Ereignisgetriebene Funktionen
1.2.0+assets.hd.remaster → Asset-Updates

Kreative 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 → Mit Zeitstempel veröffentlicht

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

🌍 Strategie für mehrere Plattformen

1.3.0+ios.optimized → iOS-spezifische Optimierungen
1.3.0+android.material3 → Aktualisierungen für Android-Design
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 Versionsverwaltung mit Bereitstellungsmetadaten

💡 Pro Tipps:
  • Verwenden Sie Build-Metadaten (+) zum Tracken, Zeitstempeln oder kosmetischen Informationen, die die Kompatibilität nicht beeinflussen
  • Verwenden Sie Vorabversionen (-) für Entwicklungskanäle, die unterschiedliche Aktualisierungsreihenfolgen benötigen
  • Combine both für maximale 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 hat bekannte Abweichungen von der Spezifikation, was zu unerwartetem Verhalten führen kann

Beispiel: npm behandelt Versionen wie 1.0.0-alpha.1 anders als die Spezifikation vorschreibt. Siehe unsere berichtete Issue und Versuchte Korrektur dies wurde nie integriert.

Gültige semantische Versionen

1.0.0 ✓ Standardrelease
2.1.3-alpha ✓ Voraussichtliche Version
1.0.0-beta.1 ✓ Voraussichtliche 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 ✗ Vorderer 'v' nicht erlaubt
1.0 ✗ Patchversion fehlt
1.0.0.0 ✗ Zu viele Versionsteile
1.0.0- ✗ Leere Voraussichtliche Version
1.0.0+ ✗ Leere Build-Metadaten

Capgo Aktualisierungsverhalten

✓ Die Strategie für Minor-Updates ermöglicht Änderungen auf der gleichen Haupt- und Minor-Version, zum Beispiel 1.0.0 -> 1.0.1
✓ Die Strategie für Patches blockiert 1.0.0 -> 1.0.1. Sie ermöglicht nur Änderungen der Suffixe wie 1.0.0-beta.1 -> 1.0.0-beta.2.
✗ Die Strategie für Major-Updates blockiert Ziel-Pakete mit einer höheren Hauptversion als die native Basis, zum Beispiel 1.0.0 -> 2.0.0
⚠ Die Downgrade-Schutzfunktion verwendet die volle semantische Vorherrschaft, sodass stabile 1.0.0 neuer ist als 1.0.0-beta.2

Dieses Werkzeug folgt der offiziellen Semantic Versioning-Spezifikation im Gegensatz zur Implementierung von npm.