Fast jedes Software-Projekt, jedes npm-Paket und jede Bibliothek traegt eine Versionsnummer wie 2.4.1. Was auf den ersten Blick beliebig wirkt, folgt einem klaren Regelwerk: Semantic Versioning, kurz SemVer. Es sorgt dafuer, dass eine Versionsnummer eine Aussage transportiert – naemlich wie stark sich etwas geaendert hat und ob ein Update gefahrlos ist.
Der Aufbau: MAJOR.MINOR.PATCH
Eine SemVer-Nummer besteht aus drei durch Punkte getrennten Zahlen. Jede hat eine feste Bedeutung:
- MAJOR (die erste Zahl): wird erhoeht, wenn es inkompatible Aenderungen gibt – sogenannte Breaking Changes, die bestehenden Code brechen koennen.
- MINOR (die mittlere Zahl): wird erhoeht, wenn neue Funktionen hinzukommen, die abwaertskompatibel sind. Alter Code laeuft weiter.
- PATCH (die letzte Zahl): wird erhoeht bei Bugfixes, die keine Schnittstelle aendern.
Aus 1.4.2 wird also bei einem Bugfix 1.4.3, bei einem neuen Feature 1.5.0 und bei einem Breaking Change 2.0.0. Wichtig dabei: Beim Erhoehen einer hoeheren Stelle werden die niedrigeren auf Null zurueckgesetzt. Ein Minor-Bump von 1.4.2 fuehrt zu 1.5.0, nicht zu 1.5.2. Genau diese Reset-Regel wird gern vergessen – der Semantic-Versioning-Bump-Rechner nimmt dir das ab und zeigt fuer jede Bump-Art sofort die korrekte neue Nummer.
Warum diese Disziplin so wichtig ist
Der eigentliche Wert von SemVer entfaltet sich beim Verwalten von Abhaengigkeiten. In einer package.json stehen oft Eintraege wie "^1.4.0" oder "~1.4.0". Diese Zeichen sind keine Deko:
- Caret (^): erlaubt alle Minor- und Patch-Updates, aber keinen Major-Sprung.
^1.4.0akzeptiert1.9.5, aber nicht2.0.0. - Tilde (~): erlaubt nur Patch-Updates.
~1.4.0akzeptiert1.4.9, aber nicht1.5.0.
Wenn alle Maintainer SemVer korrekt einhalten, kann ein Paketmanager automatisch sichere Updates ziehen, ohne dass etwas zerbricht. Genau deshalb ist es so aergerlich, wenn ein Projekt in einem vermeintlichen Patch-Release heimlich eine Schnittstelle aendert – das untergraebt das ganze Vertrauensmodell.
Pre-Release- und Build-Metadaten
SemVer kennt mehr als nur drei Zahlen. An die Version kann ein Pre-Release-Tag angehaengt werden, getrennt durch einen Bindestrich: 2.0.0-beta.1 oder 2.0.0-rc.2. Solche Versionen gelten als instabil und rangieren in der Sortierung vor der finalen 2.0.0. Damit lassen sich Alpha-, Beta- und Release-Candidate-Phasen sauber abbilden.
Zusaetzlich gibt es Build-Metadaten nach einem Pluszeichen, etwa 2.0.0+20250522. Diese werden bei der Versionsvergleichung ignoriert und dienen nur der Nachvollziehbarkeit.
Die 0.x-Phase: Sonderregeln
Solange eine Software unter 0.y.z liegt, gilt sie als in aktiver Entwicklung und potenziell instabil. In dieser Phase darf praktisch jede Aenderung Breaking sein – viele Projekte erhoehen dann die MINOR-Stelle fuer Breaking Changes und PATCH fuer alles andere. Erst mit dem Sprung auf 1.0.0 verspricht ein Projekt offiziell eine stabile API.
SemVer in der Praxis
Beim Veroeffentlichen eines Releases stellt sich jedes Mal die Frage: Major, Minor oder Patch? Eine ehrliche Antwort darauf zwingt dich, deine Aenderung einzuordnen. Hast du wirklich nur einen Fehler behoben? Oder aendert sich das Verhalten so, dass jemand seinen Code anpassen muss? Diese Reflexion ist der eigentliche Kern von SemVer.
Tools wie npm version major, git tag und CI-Pipelines automatisieren das Anheben. Wer manuell arbeitet oder den naechsten Tag im Kopf durchspielen will, ist mit dem Semantic-Versioning-Bump-Rechner schneller. Passend dazu erleichtert der Cron Generator das Planen automatischer Release- und Build-Jobs.
Fazit
SemVer ist ein Versprechen in drei Zahlen: Major bedeutet "Achtung, etwas bricht", Minor bedeutet "neue Funktionen, gefahrlos", Patch bedeutet "nur Fehler behoben". Wer dieses Schema konsequent nutzt, macht das eigene Projekt fuer alle anderen berechenbar – und das ist im Software-Oekosystem unbezahlbar.