Capgo Semver Tester

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

Native Baseline-Version

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

Remote-Version

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

Eingeben Sie zwei semantische Versionen, um Vergleich zu sehen

Was bedeutet "Native Baseline Version"

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

Capgo wird immer noch verwendet version_name um zu wissen, welches heruntergeladene Bundle derzeit installiert ist. Kanal-Semver-Politiken wie major, minor, and patch , version_build.

Capacitor config

__CAPGO_KEEP_0__ Konfiguration CapacitorUpdater.version Setzen

wenn Sie eine explizite Version durch den App wünschen. Vorteile:

Gegnerisch: Eine veraltete Konfiguration kann den falschen Versionsnummer berichten, wenn Sie vergessen, sie vor einer nativen Veröffentlichung zu aktualisieren.

Native App-Version

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

Stimmt der Binärdateien, die Benutzer von TestFlight, App Store, Play Store oder internen Tests heruntergeladen haben. Gegnerisch:

Eine Änderung erfordert eine native Build und kann je nach Plattform unterschiedlich sein, wenn sich die Release-Einstellungen verschieben. Bündelziel

Vergleichen Sie es mit Remote-Bundle-Versionen, Channel-Semver-Regeln oder Upload-Beschränkungen wie

Pro: --native-version.

Pro: 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 Paketmetadata angepasst wird.

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

Wieso 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): Bug-Fixes, sicher automatisch anzuwenden
Minor-Updates (1.0.0 → 1.1.0): Neue Funktionen, kompatibel mit der Vergangenheit
Hauptaktualisierungen (1.0.0 → 2.0.0): Unterbrechende Ä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 sichert die Stabilität Ihrer App.

Flexible Semver-Strategien: Jenseits der grundlegenden Versionsierung

Während semver streng über seine Kernformatik ist, können Sie sie für die Bedürfnisse Ihres Teams erweitern, indem Sie Vorab-Identifikatoren und Baumetadaten:

🏷️ Baumetadaten (+) - Die 'ästhetische' Ebene

1.2.0+20240315.142530

Zeitstempel für die Verfolgung von Bereitstellungen

1.2.0+ui.refresh.dark-mode

Benutzerinterface-Updatebeschreibung für das Designteam

1.2.0+build.4729.commit.a1b2c3d

CI/CD-Buildnummer und Git-Commit

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

🔧 Vorab-Identifikatoren (-) - Entwicklungskanäle

1.3.0-beta.1

Beta-Testkanal

1.3.0-hotfix.payment

Notfall-Fix-Zweig

1.3.0-feature.newapi

Funktionszweig-Testen

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

🎯 Hybrid-Ansatz - Das Beste aus beidem

1.3.0-rc.1+ui.redesign.20240315

Freigabekandidat mit UI-Metadaten und Zeitstempel

Real-World Semver Use Cases & Team Strategies

🚀 Startup / Schnelle Entwicklung

0.1.0 - Erste MVP-Freigabe

0.2.0-beta.1 - Neuer Funktionszweig-Test

0.2.0+ui.v2 - UI-Redesign-Metadaten

1.0.0 - Produktionsreif

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

🏢 Enterprise / Regulierte

2.1.0 → Vierteljährliche Veröffentlichung

2.1.1+sec.patch.cve2024 → Sicherheitspatch mit Tracking

2.2.0-rc.1+audit.ready → Vorkontrollreleasekandidat

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 → Kritischer Fehlerbehebungsrelease

1.2.1+urgent.20240315.1430 → Mit Zeitstempel veröffentlicht

Vorabversion für Tests, Metadaten für die Bereitstellungstracking

🌍 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 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, Zeitstempel oder kosmetische Informationen, die die Kompatibilität nicht beeinflussen
Verwenden Sie Vorklausel-Identifier (-) für Entwicklungs-Kanäle, die unterschiedliche Aktualisierungs-Vorrang benötigen
Combination beider für maximalen Flexibilität: 1.2.0-beta.1+ui.dark.theme.20240315
Denken Sie daran: Capgo respektiert die semver-Vorrang-Regeln, also planen Sie Ihre Kanal-Strategie 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, 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 ✓ Prerelease

1.0.0-beta.1 ✓ Prerelease mit Zahl

1.0.0+build.1 ✓ Build-Metadaten

1.0.0-rc.1+build.1 ✓ Complete Version

Ungültige semantische Versionen

v1.0.0 ✗ Führende 'v' nicht erlaubt

1.0 ✗ Fehlende Patchversion

1.0.0.0 ✗ Zu viele Versionsteile

1.0.0- ✗ Leere Prärelase

1.0.0+ ✗ Leeres Build-Metadaten

Capgo Updateverhalten

✓ Minor-Strategie ermöglicht Patch-Änderungen in derselben major.minor-Linie, zum Beispiel 1.0.0 -> 1.0.1

✓ Patch-Strategie blockiert 1.0.0 -> 1.0.1. Sie ermöglicht nur Suffix-Änderungen wie 1.0.0-beta.1 -> 1.0.0-beta.2.

✗ Major-Strategie blockiert Zielbündel mit einer höheren major als der native Basis, zum Beispiel 1.0.0 -> 2.0.0

⚠ Heruntergradschutz verwendet vollständige semver-Vorrang, sodass stabile 1.0.0 neuer ist als 1.0.0-beta.2

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