So nutzt du: Semver-Rechner
- Vergleichen: Gib zwei Versionen ein, um zu sehen, welche neuer ist und warum (inklusive Prerelease und Build-Metadaten).
- Erhöhen: Gib die aktuelle Version ein und klicke auf die Art der Änderung, um die nächste Version zu erhalten – sie wird automatisch kopiert.
- Range prüfen: Gib einen npm-Range wie
^1.2.0,~1.2,1.xoder>=1.2 <2sowie eine Liste von Versionen ein. - Lies die verständliche Erklärung und sieh, welche Versionen den Range erfüllen.
Semantische Versionierung: MAJOR.MINOR.PATCH
| Teil | Erhöhen, wenn… | Beispiel |
|---|---|---|
| MAJOR | du inkompatible Änderungen machst | 1.4.2 → 2.0.0 |
| MINOR | du abwärtskompatible Funktionen hinzufügst | 1.4.2 → 1.5.0 |
| PATCH | du abwärtskompatible Fehler behebst | 1.4.2 → 1.4.3 |
| Prerelease | du eine Testversion veröffentlichst | 2.0.0-beta.1 |
| Build-Metadaten | du einen Build markierst (bei der Reihenfolge ignoriert) | 1.4.2+sha.5114f85 |
npm-Range-Spickzettel
| Range | Bedeutung | Erlaubt |
|---|---|---|
^1.2.3 | Kompatibel mit 1.2.3 | >=1.2.3 <2.0.0 |
^0.2.3 | Bei 0.x gilt Minor als „Major“ | >=0.2.3 <0.3.0 |
~1.2.3 | Nur Patch-Updates | >=1.2.3 <1.3.0 |
1.x / 1 | Jede 1.y.z | >=1.0.0 <2.0.0 |
1.2.3 - 2.3 | Bindestrich-Bereich | >=1.2.3 <2.4.0 |
>=1.2 <1.5 || 2.x | Eine der beiden Mengen | 1.2.0–1.4.x oder 2.x |
Prereleases passen nur dann zu einem Range, wenn ein Komparator in derselben Menge ein Prerelease auf derselben major.minor.patch-Version hat – ^1.2.0 passt also nicht zu 1.3.0-beta.1, ^1.3.0-beta.0 dagegen schon. So installierst du nicht versehentlich instabile Versionen.
Ranges stehen in deiner package.json. Um die nächste Version anhand deiner Commits festzulegen, nutze den Changelog-Generator; zum Taggen des Releases den Git-Befehl-Generator.
Auch gesucht als: semver range checker, npm version range, caret vs tilde, semantic versioning, versionsnummer erhöhen, versionen vergleichen, semver prerelease, semver checker.
Passende Tools zu: Semver-Rechner
- GitHub Actions Workflow-Generator — Wähle deinen Stack, deine Trigger und Schritte aus und erhalte eine kommentierte .github/workflows/ci.yml — Installation, Zwischenspeicherung, Lint, Test, Build, eine Versionsmatrix und optional die Bereitstellung auf GitHub Pages, Vercel oder in einer Container-Registry.
- Zahlensystem-Umrechner — Gib eine Zahl in einer beliebigen Basis ein und sieh sie sofort in allen anderen.
- Diff-Checker — Füge die Originalversion und eine geänderte Version ein, um hinzugefügte, entfernte und geänderte Zeilen nebeneinander zu sehen – wobei die genauen Wörter, die sich geändert haben, in jeder Zeile hervorgehoben sind.
- YAML-Validator — Füge eine Docker-Compose-Datei, ein Kubernetes-Manifest, einen GitHub-Actions-Workflow oder beliebiges YAML ein, um Fehler genau zu finden, typische Stolperfallen zu erkennen und eine sauber formatierte Version zu erhalten.
Häufige Fragen
Kann ich das als Semver-Tester verwenden?
Was ist der Unterschied zwischen ^ und ~ in package.json?
^1.2.3 erlaubt Minor- und Patch-Updates (bis einschließlich, aber nicht 2.0.0). ~1.2.3 erlaubt nur Patch-Updates (bis 1.3.0). Bei 0.x-Versionen ist ^ strenger: ^0.2.3 erlaubt nur 0.2.x.