Zum Hauptinhalt springen
Capgo Logo

Capgo Semver-Tester

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

Die native Version, die an Capgo als version_build gesendet wird, entweder aus der Konfiguration oder aus den Metadaten des native Apps.

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

Zwei semantische Versionen eingeben, 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 wenn das Gerät den Update-Server um ein Bundle bittet. In einer Capacitor-App kann dieser Wert aus CapacitorUpdater.version in capacitor.config.*Wenn diese Einstellung nicht package.json verfügbar ist, fällt der Plugin auf die native App-Version von iOS oder Android zurück. Vergessen Sie nicht, dass es sich nicht um Ihre

Capgo still uses version_name __CAPGO_KEEP_0__ verwendet major, minorum zu wissen, welches heruntergeladene Bundle derzeit installiert ist. Kanal-semver-Politiken wie patch vergleichen Sie das Remote-Bundle gegen version_build.

Capacitor Konfiguration

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

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

Nachteil: Ein veraltetes Konfigurationsdatei kann die falsche Version melden, wenn Sie vergessen, sie vor einer nativen Veröffentlichung zu aktualisieren.

Native-App-Version

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

Vorteil: entspricht dem binären, von TestFlight, App Store, Play Store oder intern getesteten Benutzern installierten Programm.

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

Zielgruppennachverteilung

Vergleiche es mit Remote-Bundle-Versionen, Channel-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äre.

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

Für diesen Tester eingeben Sie die native Basislinie, die das Gerät sendet als version_build, und vergleichen Sie sie mit der Remote-Bundle-Version, die Sie Capgo liefern möchten.

Warum Capgo Semantic Versioning verwendet

Semantic Versioning ist die am weitesten verbreitete Versionsstandards 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): Fehlerbehebungen, 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 es, dass Capgo einem inkompatiblen Update an Ihre native 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 Vorab-Identifikatoren und 🏷️ Build-Metadaten (+) - Die "ästhetische" Ebene:

Timestamp für die Verfolgung von Bereitstellungen

1.2.0+20240315.142530
1.2.0+ui.refresh.dark-mode
Beschreibung der UI-Update für das Design-Team
1.2.0+build.4729.commit.a1b2c3d
CI/CD-Bau-Nummer und Git-Commit
Wichtig:

Build-Metadaten werden bei der Versionsvorrangigkeit ignoriert - gleicht 1.2.0+anything entspricht 1.2.0 für Capgo's Aktualisierungslogik.

🔧 Vorab-Identifikatoren (-) - Entwicklungskanäle

1.3.0-beta.1
Kanäle für Beta-Testversionen
1.3.0-hotfix.payment
Branch für dringende Reparaturen
1.3.0-feature.newapi
Branch für die Testung neuer Funktionen

Hinweis: Vorabversionen haben eine niedrigere Priorität - 1.3.0-beta.1 < 1.3.0

🎯 Hybrider Ansatz - Das Beste aus beiden Welten

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

Real-World Semver-Anwendungsfall und Teamstrategien

🚀 Startup / Schnelle Entwicklung

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

Strikte Semver mit Compliance-Metadaten

🎮 Spiele- / Kreativ-Apps

1.0.0+season.winter.2024 → Saisonales Inhalt
1.1.0+event.halloween → Ereignis-gesteuerte Funktionen
1.2.0+assets.hd.remaster → Aktualisierung von Assets

Kreatives Metadaten für Inhaltsverfolgung

⚡ Hotfix-Strategie

1.2.0 → Aktuelle Produktion
1.2.1-hotfix.payment → Kritische Fehlerbehebung
1.2.1+urgent.20240315.1430 → Freigegeben mit Zeitstempel

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

🌍 Multi-Plattform-Strategie

1.3.0+ios.optimized → iOS-spezifische Optimierungen
1.3.0+android.material3 → Android-Design-Updates
1.3.0+web.pwa.ready → PWA-Fähigkeiten

Selbe Version, plattform-spezifische Metadaten

🔄 CI/CD-Integration

1.4.0-alpha.1+build.123 → Automatisierte Voreinstellung
1.4.0+deploy.staging.456 → Staging-Deployments
1.4.0+prod.final.789 → Produktions-Deployments

Automatisierte Versionsnummer mit Deployments-Metadaten

💡 Pro-Tipps:
  • Verwende Build-Metadaten (+) für die Verfolgung, Zeitstempel oder kosmetische Informationen, die die Kompatibilität nicht beeinflussen
  • Verwende Voreinstellungs-Identifikatoren (-) für Entwicklungs-Kanäle, die unterschiedliche Aktualisierungs-Prioritäten benötigen
  • Combine both for maximum flexibility: 1.2.0-beta.1+ui.dark.theme.20240315
  • Denken Sie daran: Capgo respektiert die Vorrangregeln von semver, also planen Sie Ihre Kanalstrategie entsprechend

Wichtig: Capgo verwendet strikte semantische Versionsierung

Im Gegensatz zur semver-Implementierung von npm folgt Capgo streng der offiziellen SemVer-Spezifikation. npm's node-semver hat bekannte Abweichungen von der Spezifikation, die zu unerwartetem Verhalten führen können.

Beispiel: npm behandelt 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 ✓ Standardrelease
2.1.3-alpha ✓ Vorabversion
1.0.0-beta.1 ✓ Vorabversion mit Nummer
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' ist nicht erlaubt
1.0 ✗ Patch-Version fehlt
1.0.0.0 ✗ Zu viele Versionsteile
1.0.0- ✗ Leere Vorabversion
1.0.0+ ✗ Leere Build-Metadaten

Capgo Aktualisierungsverhalten

✓ Die Strategie der Minor-Versionen ermöglicht Patch-Änderungen in derselben Major.Minor-Linie, zum Beispiel 1.0.0 -> 1.0.1
✓ Patchstrategie blockiert 1.0.0 -> 1.0.1. Sie erlaubt nur Suffixänderungen wie 1.0.0-beta.1 -> 1.0.0-beta.2.
✗ Die Strategie für Hauptversionen zielt auf Pakete ab, die eine höhere Hauptversion als die native Basis haben, zum Beispiel 1.0.0 -> 2.0.0
⚠ Die Downgrade-Schutzfunktion verwendet die volle semantische Vorherrschaft, sodass stabiles 1.0.0 neuer ist als 1.0.0-beta.2

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