Zum Hauptinhalt springen
Capgo Logo

Capgo Semver-Tester

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

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

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 when the device asks the update server for a bundle. In a Capacitor app, that value can come from CapacitorUpdater.version wenn das Gerät den Update-Server um einen Bundle bittet. In einer __CAPGO_KEEP_0__-App kann dieser Wert aus capacitor.config.*aus package.json . Wenn diese Einstellung nicht

vorhanden ist, fällt der Plugin auf die native App-Version von iOS oder Android zurück. Nehmen Sie an, es ist Ihre Version, es sei denn, Ihre Build kopiert diesen Wert in die Konfiguration oder in die native Metadaten ein. Capgo verwendet noch immer version_name zu wissen, welches heruntergeladene Bundle derzeit installiert ist. major, minorKanal semver-Politiken wie patch , und version_build.

Capacitor config

__CAPGO_KEEP_0__-Konfiguration CapacitorUpdater.version Setzen

wenn Sie eine explizite Version von der App gesendet werden möchten. Vorteil:

es ist leicht, dasselbe über iOS- und Android-Builds zu halten. Nachteil:

ein veraltetes Konfiguration kann die falsche Version melden, wenn Sie vergessen, es vor einer nativen Veröffentlichung zu aktualisieren.

Native-App-Version CFBundleShortVersionString oder Android versionName.

Pro: entspricht der binären Software, die Benutzer von TestFlight, App Store, Play Store oder interner Testung installiert haben.

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

Bundle-Zielgruppe

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

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 native Basislinie ein, die das Gerät sendet version_build Dann vergleicht sie sich mit der Remote-Bundle-Version, die Sie Capgo liefern möchten.

Wieso verwendet Capgo Semantic Versioning?

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

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

  • Patch-Updates (1.0.0 → 1.0.1): Kleine Fehlerkorrekturen, 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): Zerstörungswürdige Änderungen, erfordern native App-Store-Veröffentlichung

Dadurch verhindert Capgo, dass ein inkompatibles Update an Ihre native code gesendet wird, was die Benutzer vor Abstürzen schützt und sicherstellt, dass Ihre App stabil bleibt.

Flexible Semver Strategien: Jenseits der Grundlagen der Versionsnummerierung

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 Baumetadaten:

🏷️ Baumechanismen (+) - Die "ästhetische" Ebene

1.2.0+20240315.142530
Timestamp für die Verfolgung von Bereitstellungen
1.2.0+ui.refresh.dark-mode
Beschreibung der UI-Update für das Designteam
1.2.0+build.4729.commit.a1b2c3d
Zielergebnis des CI/CD-Baus und Git-Commit

Wichtige Hinweise: Die Metadaten werden bei der Versionsvorrangigkeit ignoriert - 1.2.0+anything entspricht 1.2.0 für Capgo's Update-Logik.

🔧 Vorab-Identifikatoren (-) - Entwicklungskanäle

1.3.0-beta.1
Kanal für Beta-Testversion
1.3.0-hotfix.payment
Notfall-Fix-Branch
1.3.0-feature.newapi
Funktionskanal für Tests

Hinweis: Vorabversionen haben einen niedrigeren Vorrang - 1.3.0-beta.1 < 1.3.0

🎯 Hybrid Ansatz - Best of Beiden Welten

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

Real-World Semver Anwendungsfälle & Teamstrategien

🚀 Startup / Schnelle Entwicklung

0.1.0 - Erste MVP-Veröffentlichung
0.2.0-beta.1 - Neuer Funktionsumfang
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 Design-Tracking

🏢 Unternehmen / Regulierte

2.1.0 → Quartalsveröffentlichung
2.1.1+sec.patch.cve2024 → Sicherheitspatch mit Tracking
2.2.0-rc.1+audit.ready → Vorauswahl-Releasekandidat

Strikter semver mit Compliance-Metadaten

🎮 Gaming- / Kreativ-Apps

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

Kreativ-Metadaten für Inhaltstracking

⚡ Hotfix-Strategie

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

Vorabversion für die Testung, Metadaten für die Abrechnung 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 → Fähigkeiten von PWA

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-Bereitstellung
1.4.0+prod.final.789 → Produktion-Bereitstellung

Automatisierte Versionsnummer mit Metadaten für die Bereitstellung

💡 Pro-Tipps:
  • Verwenden Sie Build-Metadaten (+) für die Verfolgung, Zeitstempel oder kosmetische Informationen, die die Kompatibilität nicht beeinflussen.
  • Verwenden Sie Vorabversionen (-) für Entwicklungskanäle, die unterschiedliche Aktualisierungsreihenfolgen benötigen.
  • Combiniert man 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 Versionierung.

Im Gegensatz zur semver-Implementierung von npm folgt Capgo streng der offizielle SemVer-Spezifikation. npm's node-semver weist bekannte Abweichungen von der Spezifikation auf, was zu unerwartetem Verhalten führen kann.

Beispiel: npm behandelt Versionen wie 1.0.0-alpha.1 anders als die Spezifikation vorschreibt. Siehe unsere gemeldete Issue und versuchte Lösung die nie eingereicht wurde.

__CAPGO_KEEP_0__

1.0.0 ✓ Standardrelease
2.1.3-alpha ✓ Vorkonfigurierte Version
1.0.0-beta.1 ✓ Vorkonfigurierte Version 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 ✗ Patchversion fehlt
1.0.0.0 ✗ Zu viele Versionsteile
1.0.0- ✗ Leerer Vorkonfigurierte Version
1.0.0+ ✗ Leerer Build-Metadaten

Capgo Aktualisierungsverhalten

✓ Kleine Strategie ermöglicht Änderungen in der gleichen Hauptversion-Minor-Zeile, zum Beispiel 1.0.0 -> 1.0.1
✓ Patch-Strategie 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.
✗ Hauptstrategie blockiert Zielbündel mit einer höheren Hauptversion als der nativen Basis, zum Beispiel 1.0.0 -> 2.0.0
⚠ Heruntergrad-Schutz verwendet die volle semver-Vorrangfolge, 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.