Capgo Semver-Tester

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

Natives Basisversion

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

Remote Version

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

Anwendungs-Kontext

Plattform

Entwicklungsbuild

Laufend auf Emulator

Kanal-Einstellungen

iOS

Aktualisierungen für iOS-Geräte zulassen

Android

Aktualisierungen für Android-Geräte zulassen

Entwicklungsbuild zulassen

Aktualisierungen für Entwicklungsbuilds zulassen

Emulatoren zulassen

Aktualisierungen für Emulatoren-geräte zulassen

Automatische Downgrade unter Native deaktivieren

Verhindert Downgraden, wenn Native code ausgeführt wird

Automatische Aktualisierung deaktivieren

Major: blockiert Ziel-Major größer als version_build. Erlaubt 1.2.3 -> 1.9.0, blockiert 1.2.3 -> 2.0.0.

Zwei semantische Versionen eingeben, um Vergleich zu sehen

Was "Native Baseline Version" bedeutet

Die Native Baseline Version ist die native App-Version, die 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 die App beim Abrufen eines Bundles vom Update-Server anfragt. In einer __CAPGO_KEEP_0__-App kann dieser Wert aus capacitor.config.*vorhanden sein. Wenn diese Einstellung nicht package.json vorhanden ist, fällt der Plugin auf die native App-Version von iOS oder Android zurück. Nehmen Sie nicht an, dass es Ihre

Version ist, es sei denn, Ihre Build kopiert diesen Wert in die Konfiguration oder native Metadaten ein. Capgo verwendet immer noch version_name Wissen, welches heruntergeladene Bundle derzeit installiert ist. Kanal-semver-Politiken wie major, minorund patch den Remote-Bundle gegen version_build.

Capacitor-Konfiguration

Setzen CapacitorUpdater.version wenn Sie eine explizite Version von der App erhalten möchten.

Vorteile: leicht zu handhaben, um dasselbe über iOS- und Android-Builds zu halten.

Nachteile: Stale-Konfiguration kann falsche Versionen 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.

Vorteile: entspricht der binären Software, die Benutzern von TestFlight, App Store, Play Store oder internen Tests installiert wurde.

Nachteile: Änderungen erfordern eine native Anwendung und können je nach Plattform unterschiedlich sein, wenn sich die Release-Einstellungen verschieben.

Zielgruppen für Pakete

Vergleicht es mit Remote-Paketversionen, Channel-semver-Regeln oder Metadaten-Upload-Beschränkungen wie --min-update-versionDer Channel muss --disable-auto-update metadata.

Vorteile: verhindert das Senden von JavaScript, das eine neuere native code benötigt, an alte App-Binäre.

Nachteile: Regeln, die zu streng sind, können gültige Updates blockieren, bis der Channel oder die Paket-Metadaten angepasst werden.

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

Weshalb Capgo Semantic Versioning verwendet

Semantic Versioning ist die am weitesten verbreitete Versionsstandard in der Softwareentwicklung. Durch die Verwendung von semver stellt Capgo sicher, dass Kompatibilität und Sicherheit gewährleistet sind, 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): Bugfixes, 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): Bruchstellenä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 stellt sicher, dass Ihre App stabil bleibt.

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

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

1.2.0+20240315.142530

Zeitstempel 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

Zahl der CI/CD-Bereitstellung und Git-Commit

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

🔧 Vorabversionen (-) - Entwicklungskanäle

1.3.0-beta.1

Kanäle für Beta-Testversionen

1.3.0-hotfix.payment

Wichtige Korrektur-Branch

1.3.0-feature.newapi

Branch für neue Funktionen

Wenn Sie diese Seite verwenden, stimmen Sie unserer Datenschutzrichtlinie zu. Vorabversionen haben eine niedrigere Priorität - 1.3.0-beta.1 < 1.3.0

🎯 Hybrid-Ansatz - Das Beste aus beiden Welten

1.3.0-rc.1+ui.redesign.20240315

Freigabekandidat mit UI-Metadaten und Zeitstempel

Real-Welt-Verwendung von Semver und Teamstrategien

🚀 Startup / Schnelle Entwicklung

0.1.0 - Erste MVP-Version

0.2.0-beta.1 - Neuer Funktionsumfang

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 Überwachung von Design

🏢 Unternehmen / Regulierte

2.1.0 → Quartalsrelease

2.1.1+sec.patch.cve2024 → Sicherheitspatch mit Tracking

2.2.0-rc.1+audit.ready → Prüfungsreleasekandidat

Strict semver mit Compliance-Metadaten

🎮 Gaming- / Kreativ-Apps

1.0.0+season.winter.2024 → Saisonales Inhalt

1.1.0+event.halloween → Ereignisgetriebene Funktionen

1.2.0+assets.hd.remaster → Asset-Updates

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

Vorversion 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 → PWA-Fähigkeiten

Selbe Version, plattform-spezifische Metadaten

🔄 Integration von CI/CD

1.4.0-alpha.1+build.123 → Automatisierte Vorversion

1.4.0+deploy.staging.456 → Staging-Bereitstellung

1.4.0+prod.final.789 → Produktion-Bereitstellung

Automatisierte Versionsnummer mit Bereitstellungsmetadaten

💡 Tipps für Sie:

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
Combine both 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 weist bekannte Abweichungen von der Spezifikation auf, was zu unerwartetem Verhalten führen kann

Zum Beispiel behandelt npm Versionen wie 1.0.0-alpha.1 anders als die Spezifikation vorschreibt. Siehe unsere berichtete Issue und Versuch einer Lösung dies wurde nie integriert.

Gültige semantische Versionen

1.0.0 ✓ Standardrelease

2.1.3-alpha ✓ Vorkonfiguration

1.0.0-beta.1 ✓ Vorkonfiguration 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 ✗ Vorderer 'v' nicht erlaubt

1.0 ✗ Patchversion fehlt

1.0.0.0 ✗ Zu viele Versionsteile

1.0.0- ✗ Leere Vorkonfiguration

1.0.0+ ✗ Leere Build-Metadaten

Capgo Aktualisierungsverhalten

✓ Die Minor-Strategie ermöglicht Änderungen der Patch-Ebene in derselben Major.Minor-Linie, zum Beispiel 1.0.0 -> 1.0.1

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

✗ Die Major-Strategie blockiert Ziel-Pakete mit einer höheren Major als der native Baseline, zum Beispiel 1.0.0 -> 2.0.0

⚠ Die Downgrade-Schutzfunktion verwendet die volle semver-Vorherrschaft, sodass stabile 1.0.0 neuer ist als 1.0.0-beta.2

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