Zum Hauptinhalt springen

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 Capgo als version_build gesendet wird, aus der Konfiguration oder dem native App-Metadaten

Die dem aufgelösten Kanal zugewiesene Bundle-Version

Zwei semantische Versionen eingeben, um Vergleich zu sehen

Was bedeutet "Nativbaselinenversion"

Nativbaselinenversion ist die native App-Version, die an Capgo als version_build wenn das Gerät den Update-Server um einen Bundle bittet. In einer Capacitor-App kann dieser Wert von CapacitorUpdater.version in capacitor.config.*. If that setting is not present, the plugin falls back to the native app version from iOS or Android. Do not assume it is your package.json version, es sei denn, Ihre Build kopiert diesen Wert in die Konfiguration oder native Metadaten.

Capgo verwendet immer noch version_name um zu wissen, welches heruntergeladene Bundle derzeit installiert ist. Kanäle mit semver-Politiken wie major, minorund patch vergleichen das remote Bundle gegenüber version_build.

Capacitor-Konfiguration

Setzen Sie CapacitorUpdater.version Wenn Sie eine explizite Version wünschen, die vom App sendet.

Pro: Einfach zu halten, um es auf iOS- und Android-Builds gleich zu halten.

Con: Veraltete Konfiguration kann falsche Versionsnummern 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.

Vorteile: entspricht der Binärdatei, die Benutzer von TestFlight, App Store, Play Store oder internen Tests installiert haben.

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

Zielgruppen-Verpackung

Vergleiche es mit Remote-Bundle-Versionen, Kanal-SEMVER-Regeln oder Metadaten-Upload-Beschränkungen wie --min-update-versionDer Kanal muss verwenden --disable-auto-update metadata.

Vorteile: verhindert das Senden von JavaScript, das neueren nativen code benötigt, an alte App-Dateien.

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 geben Sie die nativen Basiswerte ein, die das Gerät sendet als version_build, und vergleichen Sie sie mit der Remote-Bundle-Version, die Sie Capgo liefern möchten.

Weshalb Capgo Semantic Versioning verwendet

Semantic Versioning ist die am weitesten verbreitete Versionsierungsnorm in der Softwareentwicklung. Durch die Verwendung von semver stellt Capgo sicher, dass die Kompatibilität und Sicherheit bei der Lieferung von Live-Updates an Ihre Capacitor-Apps gewährleistet sind.

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

  • Patch-Updates (1.0.0 → 1.0.1): Fehlerbehebungen, sicher automatisch anwenden können
  • Minor-Updates (1.0.0 → 1.1.0): New features, backward compatible
  • Mehrere Updates (1.0.0 → 2.0.0): Abbrüche, erfordern eine 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 sichert die Stabilität Ihrer App.

Flexible Semver-Strategien: Jenseits der grundlegenden Versionsierung

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

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

1.2.0+20240315.142530
🏷️ Baumeetadaten (+) - Die 'ästhetische' Ebene
Zeitstempel für die Verfolgung von Bereitstellungen
Benutzerinterface-Updatebeschreibung für das Designteam
1.2.0+build.4729.commit.a1b2c3d
Zahl der CI/CD-Bau und Git-Commit

Wichtig: Die Bau-Metadaten werden bei der Versionsvorrangung ignoriert - 1.2.0+anything Gleich 1.2.0 für Capgo's Aktualisierunglogik.

🔧 Vorabversionen-Identifikatoren (-) - Entwicklungskanäle

1.3.0-beta.1
Kanäle für Beta-Test
1.3.0-hotfix.payment
Dringender Fix-Branch
1.3.0-feature.newapi
Featurezweig-Test

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

🎯 Hybrid-Ansatz - Das Beste aus beidem

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

Semver-Anwendungsfälle in der Praxis & Teamstrategien

🚀 Startup / Schnelle Entwicklung

0.1.0 - Erstes MVP-Release
0.2.0-beta.1 - Neuer Funktionszweig-Test
0.2.0+ui.v2 - UI-Redesign-Metadaten
1.0.0 - Produktreife

Verwenden Sie 0.x.x für die Entwicklung vor 1.0, Metadaten für die Design-Überwachung

🏢 Unternehmen / Regulierte

2.1.0 → Vierteljährliche Veröffentlichung
2.1.1+sec.patch.cve2024 → Sicherheitspatch mit Tracking
2.2.0-rc.1+audit.ready → Vorprüfungs-Release-Kandidat

Strikter semver mit Compliance-Metadaten

🎮 Gaming / Kreative Apps

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

Kreative Metadaten für die Inhaltsüberwachung

⚡ Hotfix-Strategie

1.2.0 → Aktuelle Produktionsversion
1.2.1-hotfix.payment → Kritische Fehlerbehebung
1.2.1+urgent.20240315.1430 → Mit Timestamp veröffentlicht

Vorabversion für Tests, 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 → Android-Design-Updates
1.3.0+web.pwa.ready → PWA-Fähigkeiten

Selbe Version, plattform-spezifische Metadaten

🔄 Integration von CI/CD

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

Automatisierte Versionsverwaltung mit Deploy-Metadaten

💡 Pro-Tipps:
  • Verwenden Sie Build-Metadaten (+) für die Verfolgung, Timestamps oder kosmetische Informationen, die die Kompatibilität nicht beeinflussen
  • Verwenden Sie Vorkomponenten-Identifikatoren (-) für Entwicklungs-Kanäle, die unterschiedliche Update-Vorrang benötigen
  • Combine beide 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 Versionsverwaltung

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

Zum Beispiel behandelt npm Versionen wie 1.0.0-alpha.1 anders als die Spezifikation vorsieht. Siehe unsere Gemeldete Fehlermeldung und Versuchte Lösung dieser wurde nie integriert.

Gültige semantische Versionen

1.0.0 ✓ Standardrelease
2.1.3-alpha ✓ Prerelease
1.0.0-beta.1 ✓ Prerelease 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 ✗ 'v' am Anfang nicht erlaubt
1.0 ✗ Fehlende Patchversion
1.0.0.0 ✗ Zu viele Versionsteile
1.0.0- ✗ Leere Vorabversion
1.0.0+ ✗ Leeres Build-Metadaten

Capgo Aktualisierungsverhalten

✓ Minor Strategie ermöglicht Patch-Änderungen in derselben major.minor Zeile, zum Beispiel 1.0.0 -> 1.0.1
✓ Die Strategie der Patchversion 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 der Hauptversion blockiert Zielbündel mit einer höheren Hauptversion als der native Baseline, zum Beispiel 1.0.0 -> 2.0.0
⚠ Die Downgrade-Schutzfunktion verwendet die volle semantische Vorabversion, sodass stabile 1.0.0 neuer ist als 1.0.0-beta.2

Diese Werkzeug folgt der offiziellen Semantic Versioning-Spezifikation im Gegensatz zu npm's Implementierung.