Zum Hauptinhalt springen

Capgo Semver-Tester

Prüfe die Channel-Policy-Kompatibilität mit der als version_build gesendeten Native Baseline

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

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

Gib zwei SemVer-Versionen ein, um den Vergleich zu sehen

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 einem capacitor.config.*stammen. Wenn diese Einstellung nicht vorhanden ist, fällt das Plugin auf die native App-Version von iOS oder Android zurück. Geh nicht davon aus, dass es deine package.json version, es sei denn, Ihr Build kopiert diesen Wert in die config oder die native Metadaten.

Capgo verwendet 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

Setzen Sie CapacitorUpdater.version wenn die App eine explizite Version senden soll.

Vorteil: leicht, auf iOS- und Android-Builds identisch zu halten.

Contra: Eine veraltete Config kann die falsche Version melden, wenn sie vor einem nativen Release nicht aktualisiert wird.

Native App-Version

Die Plattformversion verwenden, z. B. iOS CFBundleShortVersionString oder Android versionName.

Vorteil: entspricht dem Binary, das Nutzer aus TestFlight, App Store, Play Store oder internem Testing installiert haben.

Contra: Änderungen erfordern einen Native Build und können sich je nach Plattform unterscheiden, wenn 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 --disable-auto-update metadata.

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

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

Gib für diesen Tester den nativen Baseline-Wert ein, den das Gerät sendet, version_buildund vergleiche ihn 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 automatisch anwendbar
  • Minor-Updates (1.0.0 → 1.1.0): Neue Features, abwärtskompatibel
  • Major-Updates (1.0.0 → 2.0.0): Breaking Changes, erfordern ein natives App-Store-Release

Dies verhindert, dass Capgo jemals ein inkompatibles Update an dein natives code sendet, was deine Nutzer vor Abstürzen schützt und die Stabilität deiner App garantiert.

Flexible Semver-Strategien: Mehr als nur Basis-Versionierung

Obwohl semver in 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 für Deployment-Tracking
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 entspricht 1.2.0 für die Update-Logik von Capgo.

🔧 Pre-release-Identifikatoren (-) - Development-Channels

1.3.0-beta.1
Beta-Test-Channel
1.3.0-hotfix.payment
Dringender Fix-Branch
1.3.0-feature.newapi
Feature-Branch-Testing

Hinweis: Pre-release-Versionen haben geringeren Vorrang - 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 → Quartals-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-Metadaten für Content-Tracking

⚡ Hotfix-Strategie

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

Pre-release zum Testen, Metadaten 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 → Automatisierte Pre-Release
1.4.0+deploy.staging.456 → Staging-Deployment
1.4.0+prod.final.789 → Production-Deployment

Automatisiertes Versioning mit Deployment-Metadaten

💡 Pro-Tipps:
  • Verwende Build-Metadaten (+) für Tracking, Zeitstempel oder kosmetische Infos, die die Kompatibilität nicht beeinflussen
  • Verwende Pre-Release-Identifier (-) für Entwicklungskanäle, die eine andere Update-Priorität benötigen
  • Kombiniere beides für maximale Flexibilität: 1.2.0-beta.1+ui.dark.theme.20240315
  • Denk daran: Capgo beachtet die Semver-Vorrangregeln, plane deine Channel-Strategie entsprechend.

Wichtig: Capgo verwendet striktes Semantic Versioning.

Im Gegensatz zur semver-Implementierung von npm folgt Capgo strikt der offiziellen SemVer-Spezifikation. Das node-semver von npm weicht bekannt von der Spezifikation ab, was zu unerwartetem Verhalten führen kann.

Zum Beispiel behandelt npm Versionen wie 1.0.0-alpha.1 anders als es die Spezifikation verlangt. Siehe unser gemeldetes Issue und versuchter Fix der nie gemerged wurde.

Gültige SemVer-Versionen

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 Versionsbestandteile
1.0.0- ✗ Leere 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. Sie erlaubt nur Suffix-Änderungen wie 1.0.0-beta.1 -> 1.0.0-beta.2.
✗ Die Major-Strategie blockiert Ziel-Bundles mit einer höheren Major-Version als der nativen Baseline, z. B. 1.0.0 -> 2.0.0
⚠ Der Downgrade-Schutz nutzt die vollständige semver-Präzedenz, daher ist stable 1.0.0 neuer als 1.0.0-beta.2

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