Capgo Semver-Tester

Überprüfe die semantische Versionskompatibilität für Updates deiner Capacitor-Anwendung

Lokale Version

Die Version, die deine installierte Anwendung an Capgo meldet, aus der Konfiguration oder dem native App-Metadaten.

Remote Version

Zwei semantische Versionen eingeben, um eine Vergleichsübersicht zu sehen

Was "Lokale Version" bedeutet

Lokale Version ist die auf dem Gerät bereits installierte Version, wenn es sich bei der Aktualisierung des Servers um ein Bundle handelt. In einer Capacitor-Anwendung kann dieser Wert aus CapacitorUpdater.version in capacitor.config.*. Wenn diese Einstellung nicht vorhanden ist, fällt der Plugin auf die native App-Version von iOS oder Android zurück. Stelle nicht voraus, dass es deine ist package.json Version, sofern Ihre Build-Kopie dieses Wert in die Konfiguration oder native Metadaten kopiert.

Capacitor Konfiguration

Setzen CapacitorUpdater.version wenn Sie eine explizite Version durch die App übermitteln möchten.

Vorteil: leicht zu halten, dass es sich über iOS- und Android-Builds gleich bleibt.

Nachteil: Stale-Konfiguration kann die falsche Version melden, wenn Sie vergessen, sie vor einer native Release zu aktualisieren.

Native-App-Version

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

Vorteil: entspricht der binären Software, die die Benutzer von TestFlight, App Store, Play Store oder internen Tests installiert haben.

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

Zielgruppeneinstellungen

Vergleiche es mit Remote-Bundle-Versionen, Channel-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 Channel oder die Bundle-Metadaten angepasst werden.

Für diesen Tester eingeben Sie die Version, die das Gerät als lokale meldet, und vergleichen Sie sie mit der Remote-Bundle-Version, die Sie Capgo liefern möchten.

Warum Capgo Semantic Versioning verwendet

Semantic Versioning ist die am weitesten verbreitete Versionsstandards in der Softwareentwicklung. Durch die Verwendung von semver, Capgo sichert die Kompatibilität und Sicherheit, wenn live Updates an Ihre Capacitor Apps geliefert werden.

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): Fehlerbehebungen, 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): Bruchänderungen, erfordern native App-Store-Veröffentlichung

Dies verhindert Capgo, je ein inkompatibles Update an Ihre native code zu senden, schützt Ihre Benutzer vor Abstürzen und sichert, dass Ihre App stabil bleibt.

Flexible Semver-Strategien: Jenseits der grundlegenden Versionsierung

Während semver streng über sein Kernformat ist, können Sie es für die Bedürfnisse Ihres Teams erweitern, indem Sie Vorabversionsidentifikatoren verwenden und Metadaten für die Build-Informationen:

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

1.2.0+20240315.142530

Zeitstempel für die Verfolgung der Bereitstellung

1.2.0+ui.refresh.dark-mode

Beschreibung der UI-Update für das Design-Team

1.2.0+build.4729.commit.a1b2c3d

Nummer der CI/CD-Build und Git-Commit

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

🔧 Vorab-Identifikatoren (-) - Entwicklungs-Kanäle

1.3.0-beta.1

Kanäle für Beta-Testversionen

1.3.0-hotfix.payment

Notfall-Fix-Branch

1.3.0-feature.newapi

Kanäle für Feature-Branch-Testversionen

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

🎯 Hybrider Ansatz - Das Beste aus beidem

1.3.0-rc.1+ui.redesign.20240315

Release-Kandidat mit UI-Metadaten und Datum

Echtzeit-Semver-Anwendungen und Teamstrategien

🚀 Startup / Schnelle Entwicklung

0.1.0 - Erste MVP-Version

0.2.0-beta.1 - Neuer Funktionsumfang im Test

0.2.0+ui.v2 - UI-Design-Metadaten

1.0.0 - Produktionsreife

Verwende 0.x.x für die Entwicklung vor 1.0, Metadaten für das Design-Tracking

🏢 Unternehmen / Regulierte

2.1.0 → Quartalsrelease

2.1.1+sec.patch.cve2024 → Sicherheitspatch mit Tracking

2.2.0-rc.1+audit.ready → Vorentscheidungsreleasekandidat

Strikte Semver mit Compliance-Metadaten

🎮 Spiele- / Kreativ-Apps

1.0.0+season.winter.2024 → Saisonales Inhalt

1.1.0+event.halloween → Ereignis-gesteuerte Funktionen

1.2.0+assets.hd.remaster → Asset-Updates

Kreativ-Metadaten für Inhalts-Tracking

⚡ Hotfix-Strategie

1.2.0 → Aktuelle Produktion

1.2.1-hotfix.payment → Kritische Fehlerbehebung

1.2.1+urgent.20240315.1430 → Freigegeben mit Timestamp

Vorabversion für Testen, 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 Vorschau

1.4.0+deploy.staging.456 → Staging-Deployment

1.4.0+prod.final.789 → Produktions-Deployment

Automatisierte Versionsnummerierung mit Deployment-Metadaten

💡 Pro-Tipps:

Verwende Build-Metadaten (+) für die Verfolgung, Zeitstempel oder kosmetische Informationen, die die Kompatibilität nicht beeinflussen
Verwende Vorschau-Identifikatoren (-) für Entwicklungs-Kanäle, die unterschiedliche Update-Vorrang benötigen
Combine both for maximum flexibility: 1.2.0-beta.1+ui.dark.theme.20240315
Denken Sie daran: Capgo respektiert die Vorrangregeln von semver, also planen Sie Ihre Kanalstrategie entsprechend.

Wichtig: Capgo verwendet strikte semantische Versionsierung.

Im Gegensatz zur semver-Implementierung von npm folgt Capgo der offizielle SemVer-Spezifikation streng. 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 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 ✓ Vorkomponente

1.0.0-beta.1 ✓ Vorschau 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ührende 'v' nicht erlaubt

1.0 ✗ Patchversion fehlt

1.0.0.0 ✗ Zu viele Versionsteile

1.0.0- ✗ Leere Vorschau

1.0.0+ ✗ Leere Build-Metadaten

Capgo Aktualisierungsverhalten

✓ Patch-Updates werden automatisch angewendet (1.0.0 → 1.0.1)

✓ Minor-Updates erfordern eine Kanal-Konfiguration (1.0.0 → 1.1.0)

✗ Große Updates erfordern eine native App-Store-Veröffentlichung (1.0.0 → 2.0.0)

⚠ Vorversionen erfordern eine explizite Konfiguration

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