Semver-Vergleicher

Vergleichen Sie semantische Versionsnummern. Analysieren und sortieren Sie Semver-Zeichenketten, überprüfen Sie, ob eine Version einen Bereich erfüllt, und verstehen Sie Unterschiede bei Major/Minor/Patch.

Compare Two Versions

1.2.3
OLDER
2.0.0-beta.1
MAJOR version change
MajorMinorPatchPre-release
1.2.3123
2.0.0-beta.1200beta.1

Version Range Check

1.5.0 satisfies ^1.2.0

Sort Version List

One version per line — sorted newest first

13.0.0-beta.1beta.1
22.1.0
32.1.0-11
42.0.0-rc.1rc.1
51.2.3
61.0.0
71.0.0-betabeta
81.0.0-alphaalpha

So verwenden Sie Semver-Vergleicher

  1. 1Geben Sie zwei Versionsnummern zum Vergleichen ein (z. B. 1.2.3 vs. 2.0.0).
  2. 2Sehen Sie, welche neuer ist und was sich geändert hat (major/minor/patch).
  3. 3Sortieren Sie eine Liste von Semver-Versionen.
  4. 4Überprüfen Sie, ob eine Version eine Bereichsbeschränkung wie ^1.2.0 erfüllt.
ZenovayAnalytics

Analytics, für Gründer gebaut.

  • Besucher-Tracking in Echtzeit
  • Datenschutz zuerst, kein Cookie-Banner
  • In zwei Minuten eingerichtet
Zenovay entdecken

Häufig gestellte Fragen

Was ist semantische Versionierung?
Semantische Versionierung (semver) ist eine Versionierungskonvention unter Verwendung des Formats MAJOR.MINOR.PATCH. MAJOR: inkompatible API-Änderungen (Breaking). MINOR: neue abwärtskompatible Funktionalität. PATCH: abwärtskompatible Fehlerbehebungen. Vorveröffentlichungsversionen hängen einen Bindestrich und Bezeichner an: 1.0.0-alpha, 1.0.0-beta.1, 1.0.0-rc.1. Build-Metadaten hängen ein Pluszeichen an: 1.0.0+build.42. Definiert auf semver.org von Tom Preston-Werner (GitHub-Mitgründer).
Wie werden semver-Versionen verglichen?
Versionen werden von links nach rechts verglichen: zunächst MAJOR, dann MINOR, dann PATCH. Wenn diese gleich sind, hat eine Vorveröffentlichungsversion niedrigere Priorität als die Veröffentlichung: 1.0.0-alpha < 1.0.0. Vorveröffentlichungsbezeichner werden als Zahlen verglichen, wenn numerisch, ansonsten als Zeichenfolgen (lexikographisch). Längere Vorveröffentlichung hat höhere Priorität, wenn alle vorherigen Felder übereinstimmen: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2.
Was bedeuten npm-Versionierungsbereichsoperatoren?
^1.2.3 (Caret): kompatibel mit, erlaubt MINOR- und PATCH-Updates — ≥1.2.3 <2.0.0. ~1.2.3 (Tilde): ungefähr gleichwertig, erlaubt nur PATCH-Updates — ≥1.2.3 <1.3.0. 1.2.x oder 1.2.*: jeder PATCH. * oder x: jede Version. >1.2.3, >=1.2.3, <2.0.0: explizite Bereiche. 1.2.3 - 2.3.4: inklusiver Bereich. Diese Bereiche werden von npm, Yarn, pnpm und Tools wie Renovate und Dependabot ausgewertet.
Wann sollte ich MAJOR vs MINOR vs PATCH erhöhen?
MAJOR (x.0.0): wenn Sie inkompatible API-Änderungen vornehmen — entfernte Funktionen, geänderte Funktionssignaturen, Breaking Behavior Changes, gelöschte CLI-Flags. MINOR (1.x.0): wenn Sie Funktionalität auf abwärtskompatible Weise hinzufügen — neue Funktionen, neue optionale Parameter, neue Konfigurationsoptionen. PATCH (1.0.x): wenn Sie abwärtskompatible Fehlerbehebungen vornehmen — Behebung falschen Verhaltens, Sicherheits-Patches, Leistungsverbesserungen ohne API-Änderung.
Was ist der Unterschied zwischen Vorveröffentlichung und Build-Metadaten?
Vorveröffentlichung (1.0.0-alpha.1): beeinflusst die Versionspriorität — 1.0.0-alpha.1 < 1.0.0. Verwendet für Alpha-, Beta-, Release-Kandidaten. Build-Metadaten (1.0.0+build.1): beeinflussen NICHT die Versionspriorität — 1.0.0+build.1 == 1.0.0 für Vergleichszwecke. Build-Metadaten werden häufig für CI-Build-Nummern, Git-Commit-Hashes oder Build-Zeitstempel verwendet. Gemäß semver-Spezifikation sind zwei Versionen, die sich nur in Build-Metadaten unterscheiden, gleich.