Semver-Rechner

Semantischer Versionierungsrechner — Versionen erhöhen, Semver-Zeichenketten analysieren und überprüfen, ob eine Version einen Versionsbereich erfüllt.

Parsed Version

Major

1

Minor

2

Patch

3

Bumped Versions

Patch1.2.4Bug fix / minor change
Minor1.3.0New feature (backwards compatible)
Major2.0.0Breaking change

Version Range Checker

Satisfies

So verwenden Sie Semver-Rechner

  1. 1Geben Sie eine semantische Versionskette ein (z. B. 1.2.3).
  2. 2Sehen Sie die erhöhten Major-, Minor- und Patch-Versionen.
  3. 3Geben Sie einen Versionsbereich ein, um die Kompatibilität zu überprüfen.
  4. 4Fügen Sie Vorabversionsidentifizierer und Build-Metadaten hinzu.
ZenovayAnalytics

Sehen Sie, wer gerade auf Ihrer Seite ist.

  • 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 ein Versionierungsschema mit dem Format MAJOR.MINOR.PATCH: MAJOR — inkompatible API-Änderungen; MINOR — neue abwärtskompatible Funktionen; PATCH — abwärtskompatible Fehlerbehebungen. Zum Beispiel: 1.0.0 → 1.0.1 (Patch-Fix), 1.0.1 → 1.1.0 (neue Funktion), 1.1.0 → 2.0.0 (Breaking Change). Vorveröffentlichungsversionen verwenden einen Bindestrich: 1.0.0-alpha.1, 1.0.0-beta.2, 1.0.0-rc.1. Build-Metadaten verwenden +: 1.0.0+build.123.
Was bedeuten npm-Versionierungsbereichsspezifizierer?
^1.2.3 (Caret) — erlaubt MINOR- und PATCH-Updates: >=1.2.3 <2.0.0. Häufig in package.json verwendet. ~1.2.3 (Tilde) — erlaubt nur PATCH-Updates: >=1.2.3 <1.3.0. Restriktiver. >=1.2.3 — jede Version gleich oder höher. 1.2.3 — nur exakte Version. * — jede Version. 1.x oder 1.X — jeder Patch für Major 1. 1.2.x — jeder Patch für 1.2. Bereiche können kombiniert werden: >=1.0.0 <2.0.0 (gleichwertig mit ^1.0.0 für Non-Zero-Major).
Wann sollte ich die Haupt-, Neben- oder Patch-Version erhöhen?
Erhöhen Sie PATCH für: Fehlerbehebungen, Sicherheits-Patches, Leistungsverbesserungen, Dokumentationsänderungen — nichts, das die öffentliche API ändert. Erhöhen Sie MINOR für: neue Funktionen, neue Funktionen/Methoden, Veralterung bestehender Funktionalität (aber nicht Entfernung) — alles abwärtskompatibel. Erhöhen Sie MAJOR für: Entfernung oder Umbenennung öffentlicher APIs, Änderung von Funktionssignaturen auf inkompatible Weise, Änderung des Standardverhaltens, das zuvor stabil war. Verwenden Sie im Zweifelsfall MINOR — Sie können immer eine MAJOR-Version später veröffentlichen, wenn nötig.
Was ist der Unterschied zwischen 0.x.y und 1.x.y Versionierung?
Unter semver kennzeichnet 0.MAJOR.MINOR die anfängliche Entwicklung, in der sich alles ändern kann. Die standardmäßige Patch-/Minor-/Major-Semantik gilt nicht streng unter 1.0.0 — Breaking Changes können in MINOR-Bumps auftreten. Viele Projekte verwenden 0.x.y während der Entwicklung und veröffentlichen 1.0.0, wenn die API stabil ist. npm und andere Paketmanager respektieren dies und behandeln ^0.1.0 als >=0.1.0 <0.2.0 (nicht das übliche Caret-Verhalten), was ^0.x.y effektiv zu einer Tilde macht.
Was ist ein Release-Kandidat und wann sollte ich ihn verwenden?
Ein Release-Kandidat (rc) ist eine Vorveröffentlichungsversion, die zur endgültigen Veröffentlichung werden könnte, wenn keine Fehler gefunden werden: 1.0.0-rc.1, 1.0.0-rc.2. Die Vorveröffentlichungsprogression verläuft typischerweise: alpha (früh, instabil) → beta (Funktionen fertig, kann Fehler enthalten) → rc (produktionsreifer Kandidat). Vorveröffentlichungsversionen haben niedrigere Priorität als die Veröffentlichung: 1.0.0-rc.1 < 1.0.0. Sie sind in der semver-Bereichsauflösung der meisten Paketmanager ausgeschlossen, es sei denn, sie werden explizit angefordert.