01
Version und Bereich unterscheiden
Versionen brauchen drei Zahlenteile. Bereiche erlauben Kurzformen wie 1.2 und ^0.2.3. Ein leerer Bereich oder OR-Zweig gilt als Platzhalter.
Entwicklerwerkzeuge
Semver-RechnerVorrang und Bereichstreffer getrennt prüfen
Einen Versionsbereich testen, zwei Releases vergleichen oder die nächste Nummer berechnen.
Semver-Rechner
Versionen (eine pro Zeile)
Die Eingabe wird in diesem Browser verarbeitet und nicht an einen Server gesendet.
Ergebnis
Eingabe hinzufügen oder ein Beispiel laden.
Optionen
Nur exakte SemVer-2.0.0-Versionen: keine äußeren Leerzeichen, v-Präfixe oder fehlenden Teile. Kernzahlen und rein numerische Vorabbezeichner dürfen keine führenden Nullen haben; Build-Bezeichner dürfen sie enthalten.
npm-Bereiche erlauben ^, ~, Vergleiche, x, Bindestrichbereiche und ||. Leere Bereiche und leere OR-Zweige gelten als Platzhalter.
Vorabversionen sind ausgeschlossen, außer ein Vergleich derselben Gruppe nennt eine Vorabversion mit identischem major.minor.patch.
Build-Metadaten ändern den Vorrang nicht. Gleichrangige Versionen behalten beim Sortieren ihre Eingabereihenfolge.
Werkzeuggrenzen: 1000 Zeilen, 100000 UTF-16-Einheiten, 256 Zeichen je Version, 4096 je Bereich. Kernzahlen und rein numerische Vorabbezeichner dürfen 9007199254740991 nicht überschreiten. Für Build-Bezeichner gilt diese Zahlengrenze nicht.
Eingabe oder Optionen geändert. Vor dem Export das Ergebnis aktualisieren.
Der Semver-Rechner hilft, wenn eine neuere Beta nicht zum gewünschten Abhängigkeitsbereich passt. Prüfen Sie Versionsvorrang und Bereichsbedingungen getrennt, bevor Sie eine Paketvorgabe ändern.
Versionen vergleichen erfordert mehr als Textsortierung: 1.10.0 folgt auf 1.9.0. Auch Pre-Release-Kennzeichnungen haben Regeln für Zahlen und Text, die eine normale Sortierung nicht abbildet.
Warum den Semver-Rechner nutzen?
Eine ausgeschlossene Beta verstehen
Der Semver-Rechner zeigt erweiterte npm-Vergleiche neben jedem Ergebnis. Eine Version kann innerhalb der numerischen Grenzen liegen und dennoch an der Vorabregel scheitern.
Build-Kennzeichnungen behalten
1.2.3+build.1 und 1.2.3+build.7 haben denselben Vorrang. Ihre Reihenfolge bleibt erhalten, statt durch die Build-Nummer ein neueres Release vorzutäuschen.
Drei Prüfungen vor dem Ergebnis
02
Voraboption bewusst wählen
Sie ist zunächst ausgeschaltet. Das Einschalten ändert die Bereichsprüfung, nicht die strenge Versionssyntax. Bei 0.x besonders auf die erweiterten Vergleiche achten.
03
Ersetzungen zuerst prüfen
Beispiel und Leeren zeigen eine vollständige Vorschau von Eingaben und Optionen. Erst Übernehmen ersetzt sie; Rückgängig stellt den vorherigen Zustand her. Automatik wartet 350 ms, manuell geht auch Ctrl/Cmd+Enter.
Vier Prüfungen für Releases
Bereiche für Listen testen
Eine Version je Zeile gegen npm-Vergleiche, ^, ~, Platzhalter, Bindestrichbereiche und OR-Gruppen prüfen.
Vorrang vergleichen
Major, Minor, Patch und Vorabbezeichner bestimmen die Reihenfolge. Build-Metadaten entscheiden nicht über neuer oder älter.
Stabil sortieren
Auf- und absteigend sortieren. Ungültige Zeilen bleiben mit ursprünglichen Zeilennummern am Ende; gleichrangige Versionen behalten ihre Eingabereihenfolge.
Version erhöhen
Sieben Typen: major, minor, patch, premajor, preminor, prepatch und prerelease. Die berechnete Version ersetzt die Quelle nicht automatisch.
Syntax und Rechengrenzen
- Strenge Versionsstrings
- Nur exakte SemVer-2.0.0-Versionen: keine äußeren Leerzeichen, v-Präfixe oder fehlenden Teile. Kernzahlen und rein numerische Vorabbezeichner dürfen keine führenden Nullen haben; Build-Bezeichner dürfen sie enthalten. Build-Metadaten ändern den Vorrang nicht. Gleichrangige Versionen behalten beim Sortieren ihre Eingabereihenfolge.
- npm-Bereichsregeln
- npm-Bereiche erlauben ^, ~, Vergleiche, x, Bindestrichbereiche und ||. Leere Bereiche und leere OR-Zweige gelten als Platzhalter. Vorabversionen sind ausgeschlossen, außer ein Vergleich derselben Gruppe nennt eine Vorabversion mit identischem major.minor.patch.
- Begrenzte Eingaben
- Werkzeuggrenzen: 1000 Zeilen, 100000 UTF-16-Einheiten, 256 Zeichen je Version, 4096 je Bereich. Kernzahlen und rein numerische Vorabbezeichner dürfen 9007199254740991 nicht überschreiten. Für Build-Bezeichner gilt diese Zahlengrenze nicht.
- Erhöhungsverhalten
- Erhöhen entfernt Build-Metadaten. Neue Vorabzähler beginnen bei 0. Eine leere Kennzeichnung behält den vorhandenen Vorabbezeichner bei und erhöht dessen Zähler.
- Keine Paketinstallation
- Keine Registry-Abfrage, Installation oder Projektänderung. Leere Listenzeilen sind ungültig; ein einzelner abschließender Zeilenumbruch ist nur ein Abschluss. Ein Bereichstreffer beweist keine API-Kompatibilität.
Fragen zum Semver-Rechner
Wie unterscheiden sich ~ und ^ in package.json?
~1.2.3 erlaubt stabile Versionen ab 1.2.3 unter 1.3.0; ^1.2.3 reicht bis unter 2.0.0. Caret hält den ersten von links nicht nullwertigen Teil fest: ^0.2.3 endet vor 0.3.0, ^0.0.3 vor 0.0.4.
Erfasst Caret die neueste Vorabversion?
Normalerweise nicht. Der Semver-Rechner folgt npm: Ohne Voraboption muss ein Vergleich derselben Gruppe eine Vorabversion mit identischem major.minor.patch nennen. Das Veröffentlichungsdatum spielt hier keine Rolle.
Wozu dienen Build-Metadaten?
Sie können einen Build oder Commit kennzeichnen, ändern aber den Vorrang nicht. Nur nach + unterschiedliche Versionen sind gleichrangig und behalten beim Sortieren ihre Reihenfolge.
Kann ich verschiedene Tag-Formate gemeinsam sortieren?
Nur strenge SemVer-Versionen werden sortiert. v1.2.3 oder 1.10-alpine3 werden als ungültig am Ende behalten, nicht stillschweigend umgewandelt.
Wie füge ich ein alpha-Suffix hinzu?
Eine Voraberhöhung wählen und alpha als Kennzeichnung setzen. premajor macht aus 1.2.3 die Version 2.0.0-alpha.0. Für einen vorhandenen Bezeichner kann das Feld leer bleiben, um dessen Zähler weiterzuführen.
Unerwartetes Versionsergebnis?
Semver-Rechner ausprobieren
Der Semver-Rechner prüft Ihre Release-Liste. Lesen Sie die Bereichserklärung und speichern Sie den aktuellen Bericht.