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 nativen App-Metadaten.

Remote Version

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

Was "Lokale Version" bedeutet

Die Lokale Version ist die Version, die bereits auf dem Gerät installiert ist, wenn es den Update-Server um ein Bundle bittet. In einer Capacitor-App kann dieser Wert aus CapacitorUpdater.version in capacitor.config.*. Wenn diese Einstellung nicht package.json vorhanden ist, fällt der Plugin auf die native App-Version von iOS oder Android zurück. Stelle nicht automatisch an, dass es deine

Capacitor config

__CAPGO_KEEP_0__-Konfiguration CapacitorUpdater.version Setzen Sie dies, wenn Sie eine explizite Version über die App senden möchten.

Vorteil: es ist einfach, dasselbe auf iOS- und Android-Builds zu halten.

Nachteil: Ein veraltetes Konfigurationsdatei kann die falsche Version melden, wenn Sie vergessen, sie vor einer nativen Veröffentlichung zu aktualisieren.

Native App-Version

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

Vorteil: passt sich der von Benutzern installierten Binärdatei aus TestFlight, App Store, Play Store oder internen Tests an.

Nachteil: Eine Änderung erfordert eine native Build und kann sich je nach Plattform unterscheiden, wenn sich die Einstellungen für die Veröffentlichung verschieben.

Zielgruppierung von Bundeln

Vergleichen Sie es mit Remote-Bundle-Versionen, Kanal-SEMVER-Regeln oder Upload-Beschränkungen wie --native-version.

Vorteil: verhindert das Senden von JavaScript, das neueren nativen code bedarf, an alte App-Dateien.

Nachteil: 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 Version ein, die das Gerät als lokale Meldung ausgeben würde, und vergleichen Sie sie dann mit der Remote-Bundle-Version, die Sie Capgo liefern möchten.

Warum Capgo Semantic Versioning verwendet

Semantic Versioning ist die am weitesten verbreitete Versionsierungsnorm in der Softwareentwicklung. Durch die Verwendung von semver sichert Capgo die Kompatibilität und Sicherheit bei der Lieferung von Live-Updates an Ihre Capacitor-Apps.

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 zum automatischen Anwenden anzuwenden
Kleine Updates (1.0.0 → 1.1.0): Neue Funktionen, rückwärts kompatibel
Große Updates (1.0.0 → 2.0.0): Abbrüche, 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 stellt sicher, dass Ihre App stabil bleibt.

Flexible Semver-Strategien: Jenseits der Grundlagen der Versionsnummerierung

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

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

1.2.0+20240315.142530

Zeitstempel für die Verfolgung von Bereitstellungen

1.2.0+ui.refresh.dunkelmodus

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

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 gleicht 1.2.0 für Capgo's Update-Logik.

🔧 Vorab-Identifikatoren (-) - Entwicklungskanäle

1.3.0-beta.1

Kanäle für Beta-Test

1.3.0-Hotfix-Zahlung

Dringender Fixzweig

1.3.0-feature.newapi

Zweig für die Funktionstestung

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

🎯 Hybridansatz - Das Beste aus beiden Welten

1.3.0-rc.1+ui.redesign.20240315

Freigabekandidat mit UI-Metadaten und Zeitstempel

Real-World-Semver-Anwendungsfall und Teamstrategie

🚀 Startup / Schnelle Entwicklung

0.1.0 - Erster MVP-Release

0.2.0-beta.1 - Neuer Funktionszweig für die Testung

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 die Design-Verfolgung

🏢 Unternehmens- / Regulierungsanforderungen

2.1.0 → Quartalsrelease

2.1.1+sec.patch.cve2024 → Sicherheitspatch mit Tracking

2.2.0-rc.1+audit.ready → Vorentscheidungs-Releasekandidat

Strikter semver mit Compliance-Metadaten

🎮 Spiele- / Kreativ-Apps

1.0.0+season.winter.2024 → Saisonale Inhalte

1.1.0+event.halloween → Ereignis-gesteuerte Features

1.2.0+assets.hd.remaster → Asset-Updates

Kreative Metadaten für Inhaltsverfolgung

⚡ Hotfix-Strategie

1.2.0 → Aktuelle Produktionsversion

1.2.1-hotfix.payment → Kritischer Fehlerbehebungsrelease

1.2.1+urgent.20240315.1430 → Mit Timestamp veröffentlicht

Vorabversion für Tests, Metadaten für die Bereitstellung verfolgen

🌍 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 Vorschauversion

1.4.0+deploy.staging.456 → Staging-Bereitstellung

1.4.0+prod.final.789 → Produktionsbereitstellung

Automatisierte Versionsnummerierung mit Bereitstellungsmetadaten

💡 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 Aktualisierungsreihenfolge 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 Versionsnummerierung

Im Gegensatz zur semver-Implementierung von npm folgt Capgo streng der offiziellen 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 vorsieht. Siehe unsere berichtete Issue und versuchte Fix der 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 ✓ Vollständige Version

Ungültige Semantische Versionen

v1.0.0 ✗ Führt ein führendes 'v' nicht zu

1.0 ✗ Mangelnde Patchversion

1.0.0.0 ✗ Zu viele Versionsteile

1.0.0- ✗ Leere Vorabversion

1.0.0+ ✗ Leeres Build-Metadaten

Capgo Aktualisierungsverhalten

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

✓ Mäßige 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)

⚠ Vorabversionen erfordern eine explizite Konfiguration

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