Zum Hauptinhalt springen

Capgo Semver Tester

Prüfe die Channel-Policy-Kompatibilität gegen die als version_build gesendete Native Baseline

Die native Version, die als version_build an Capgo gesendet wird – aus der Config oder den nativen App-Metadaten.

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

Gib zwei semantische Versionen ein, um sie zu vergleichen

Was „Native Baseline Version“ bedeutet

Die Native Baseline Version ist die native App-Version, die an Capgo gesendet wird, version_build wenn das Gerät den Update-Server nach einem Bundle fragt. In einer Capacitor-App kann dieser Wert aus CapacitorUpdater.version in capacitor.config.*stammen. Falls diese Einstellung nicht vorhanden ist, nutzt das Plugin die native App-Version von iOS oder Android. Gehe nicht davon aus, dass es deine package.json Version ist, es sei denn, dein Build kopiert diesen Wert in die Config oder native Metadaten.

Capgo nutzt weiterhin version_name um zu wissen, welches heruntergeladene Bundle aktuell installiert ist. Channel-Semver-Policies wie major, minor, und patch vergleichen das Remote-Bundle mit version_build.

Capacitor Konfiguration

Setze CapacitorUpdater.version wenn die App eine explizite Version anfordern soll.

Pro: einfach über iOS- und Android-Builds hinweg konsistent zu halten.

Contra: veraltete Configs können die falsche Version melden, wenn man das Update vor einem Native Build vergisst.

Native App-Version

Nutze die Plattform-Version, wie z. B. iOS CFBundleShortVersionString oder Android versionName.

Pro: entspricht der Binärdatei, die User via TestFlight, App Store, Play Store oder internem Testing installiert haben.

Contra: Änderungen erfordern einen Native Build und können je nach Plattform variieren, falls Release-Einstellungen abweichen.

Bundle-Targeting

Vergleiche es mit Remote-Bundle-Versionen, Channel-Semver-Regeln oder Upload-Constraints für Metadaten wie --min-update-version. Der Channel muss verwenden --disable-auto-update metadata.

Pro: Verhindert, dass JavaScript an alte App-Binaries gesendet wird, das ein neueres natives code benötigt.

Contra: Zu strikte Regeln können gültige Updates blockieren, bis der Channel oder die Bundle-Metadaten angepasst werden.

Gib für diesen Tester die native Baseline ein, die das Gerät sendet, version_buildund vergleiche sie mit der Remote-Bundle-Version, die Capgo ausliefern soll.

Warum Capgo Semantic Versioning nutzt

Semantische Versionierung ist der am weitesten verbreitete Versionierungsstandard in der Softwareentwicklung. Durch die Nutzung von semver stellt Capgo Kompatibilität und Sicherheit bei der Bereitstellung von Live Updates für deine Capacitor Apps sicher.

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): Bugfixes, sicher für automatische Updates
  • Minor-Updates (1.0.0 → 1.1.0): Neue Features, abwärtskompatibel
  • Major-Updates (1.0.0 → 2.0.0): Breaking Changes, erfordern ein Native Build im App Store

Dadurch wird verhindert, dass Capgo jemals ein inkompatibles Update an dein natives code sendet. Das schützt deine Nutzer vor Abstürzen und sorgt für eine stabile App.

Flexible Semver-Strategien: Mehr als nur Basis-Versionierung

Obwohl semver bei seinem Kernformat strikt ist, kannst du es für die Bedürfnisse deines Teams erweitern mit Pre-release-Identifikatoren und Build-Metadaten:

🏷️ Build-Metadaten (+) – Die „kosmetische“ Ebene

1.2.0+20240315.142530
Zeitstempel zur Deployment-Verfolgung
1.2.0+ui.refresh.dark-mode
UI-Update-Beschreibung für das Design-Team
1.2.0+build.4729.commit.a1b2c3d
CI/CD Build-Nummer und Git-Commit

Wichtig: Build-Metadaten werden bei der Versionspriorität ignoriert – 1.2.0+anything ist gleich 1.2.0 für die Update-Logik von Capgo.

🔧 Pre-release Identifiers (-) – Dev-Channels

1.3.0-beta.1
Beta-Test-Channel
1.3.0-hotfix.payment
Branch für dringende Fixes
1.3.0-feature.newapi
Feature-Branch-Testing

Hinweis: Pre-release-Versionen haben eine geringere 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
Release Candidate mit UI-Metadaten und Zeitstempel

Semver in der Praxis & Team-Strategien

🚀 Startup / Schnelle Entwicklung

0.1.0 - Erster MVP-Release
0.2.0-beta.1 - Testing neuer Features
0.2.0+ui.v2 - UI-Redesign Metadaten
1.0.0 - Production-ready

0.x.x für Pre-1.0 nutzen, Metadaten für Design-Tracking

🏢 Enterprise / Reguliert

2.1.0 → Quartalsweiser Release
2.1.1+sec.patch.cve2024 → Security-Patch mit Tracking
2.2.0-rc.1+audit.ready → Pre-Audit Release Candidate

Striktes Semver mit Compliance-Metadaten

🎮 Gaming / Kreativ-Apps

1.0.0+season.winter.2024 → Saisonale Inhalte
1.1.0+event.halloween → Event-basierte Features
1.2.0+assets.hd.remaster → Asset-Updates

Creative Metadata für Content-Tracking

⚡ Hotfix-Strategie

1.2.0 → Aktuelle Production
1.2.1-hotfix.payment → Kritischer Bugfix
1.2.1+urgent.20240315.1430 → Release mit Zeitstempel

Pre-release zum Testen, Metadata für Deployment-Tracking

🌍 Multi-Platform-Strategie

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

Gleiche Version, plattformspezifische Metadaten

🔄 CI/CD-Integration

1.4.0-alpha.1+build.123 → Automatisierter Pre-Release
1.4.0+deploy.staging.456 → Staging-Deployment
1.4.0+prod.final.789 → Production-Deployment

Automatisches Versioning mit Deployment-Metadaten

💡 Pro-Tipps:
  • Verwende Build-Metadaten (+), um Tracking, Zeitstempel oder rein kosmetische Infos ohne Einfluss auf die Kompatibilität zu speichern
  • Verwende Pre-release-Identifikatoren (-), um für Development-Channels eine andere Update-Priorität festzulegen
  • Beides kombinieren für maximale Flexibilität: 1.2.0-beta.1+ui.dark.theme.20240315
  • Hinweis: Capgo folgt den SemVer-Prioritätsregeln; plane deine Channel-Strategie entsprechend.

Wichtig: Capgo nutzt striktes Semantic Versioning.

Im Gegensatz zur SemVer-Implementierung von npm folgt Capgo strikt der offiziellen SemVer-Spezifikation. Das node-semver von npm weist bekannte Abweichungen auf, die zu unerwartetem Verhalten führen können.

Beispielsweise behandelt npm Versionen wie 1.0.0-alpha.1 anders, als es die Spezifikation vorgibt. Siehe unseren gemeldeten Issue und Fix-Versuch der nie gemerged wurde.

Gültige Semantic Versions

1.0.0 ✓ Standard Release
2.1.3-alpha ✓ Pre-release
1.0.0-beta.1 ✓ Pre-release 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ührendes 'v' nicht erlaubt
1.0 ✗ Patch-Version fehlt
1.0.0.0 ✗ Zu viele Versionsanteile
1.0.0- ✗ Leeres Pre-release
1.0.0+ ✗ Leere Build-Metadaten

Capgo Update-Verhalten

✓ Die Minor-Strategie erlaubt Patch-Änderungen innerhalb derselben Major.Minor-Version, zum Beispiel 1.0.0 -> 1.0.1
✓ Patch-Strategie blockiert 1.0.0 -> 1.0.1. Erlaubt nur Suffix-Änderungen wie 1.0.0-beta.1 -> 1.0.0-beta.2.
✗ Major-Strategien blockieren Bundles mit einer höheren Major-Version als der Native Build, z. B. 1.0.0 -> 2.0.0
⚠ Der Downgrade-Schutz nutzt die volle SemVer-Präzedenz, sodass die stabile 1.0.0 neuer ist als 1.0.0-beta.2

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