guides

Semantic Versioning, fast immer zu SemVer abgekuerzt, ist ein einfacher Satz von Regeln zur Nummerierung von Software-Releases, sodass die Versionsnummer selbst verraet, was sich geaendert hat. Statt eines bedeutungslosen Zaehlers besteht eine SemVer-Version aus drei Zahlen - MAJOR.MINOR.PATCH, wie 2.4.1 - und jede Position hat eine festgelegte Bedeutung. Sobald man die Regeln kennt, kann man eine Versionserhoehung ansehen und sofort verstehen, ob ein Update sicher ist, Funktionen hinzufuegt oder den eigenen Code brechen koennte.

Die drei Teile beantworten jeweils eine andere Frage. MAJOR (die erste Zahl) erhoeht sich, wenn man inkompatible, brechende Aenderungen an der oeffentlichen API vornimmt - ein Upgrade kann erfordern, dass man den eigenen Code anpasst. MINOR (die zweite) erhoeht sich, wenn man neue Funktionalitaet auf abwaertskompatible Weise hinzufuegt - neue Funktionen, die man uebernehmen oder ignorieren kann. PATCH (die dritte) erhoeht sich bei abwaertskompatiblen Fehlerbehebungen - sichere Korrekturen, die nichts daran aendern, wie die Software genutzt wird.

Es gibt zwei mechanische Regeln, ueber die Leute stolpern. Wenn man MAJOR erhoeht, setzt man MINOR und PATCH auf null zurueck: nach 1.4.2 wird eine brechende Aenderung zu 2.0.0, nicht zu 2.4.2. Wenn man MINOR erhoeht, setzt man PATCH auf null zurueck: nach 1.4.2 wird eine neue Funktion zu 1.5.0. Die Zahlen rechts starten also immer neu, wenn eine Zahl zu ihrer Linken steigt.

SemVer hat ausserdem eine spezielle Regel fuer die fruehe Entwicklung. Jede Version, die mit 0 beginnt - wie 0.3.1 - gilt als instabil, und die normalen Garantien gelten nicht vollstaendig. Waehrend 0.x kann sich die API jederzeit aendern, daher sollte man solche Releases mit Vorsicht behandeln. Der Sprung zu 1.0.0 ist ein bewusstes Signal: er bedeutet, dass der Autor sich auf eine stabile oeffentliche API und die Einhaltung der SemVer-Regeln von da an festlegt.

Ueber die drei Kernzahlen hinaus unterstuetzt SemVer Pre-Release- und Build-Kennungen. Eine Pre-Release-Version fuegt einen Bindestrich und eine Kennung hinzu, etwa 1.0.0-alpha, 1.0.0-beta.2 oder 1.0.0-rc.1, und sie hat eine niedrigere Prioritaet als das finale Release - so kommt 1.0.0-rc.1 vor 1.0.0. Build-Metadaten koennen nach einem Pluszeichen hinzugefuegt werden, wie 1.0.0+20260715, werden aber beim Vergleich von Versionen ignoriert. So koennen Teams Testbuilds ausliefern, ohne vorzugeben, dass es fertige Releases sind.

Der Grund, warum das alles wichtig ist, ist die Verwaltung von Abhaengigkeiten. Wenn dein Projekt von einer Bibliothek abhaengt, legst du selten eine exakte Version fuer immer fest; du erlaubst einen Bereich. Paketmanager nutzen SemVer, um diese Bereiche sicher zu machen. In npm bedeutet zum Beispiel ein Caret-Bereich wie ^1.2.3 jede Version ab 1.2.3 bis, aber ohne 2.0.0 - alle abwaertskompatiblen Updates, keines der brechenden. Ein Tilde-Bereich wie ~1.2.3 ist enger und erlaubt Patch-Updates bis, aber ohne 1.3.0.

Diese Bereiche funktionieren nur, weil sich alle einig sind, was eine Versionserhoehung bedeutet. Wenn eine Bibliothek eine brechende Aenderung ausliefert, aber nur PATCH erhoeht, kann sie stillschweigend jedes Projekt brechen, das dem Bereich vertraut hat. Das ist der Gesellschaftsvertrag im Herzen von SemVer: die Zahl ist ein Versprechen ueber Kompatibilitaet, und sie einzuhalten ist das, was das gesamte Oekosystem automatischer Updates davor bewahrt, auseinanderzufallen.

SemVer ist durch eine kurze, gut lesbare Spezifikation auf semver.org definiert, und es ist das Schema, das von npm, Cargo und unzaehligen anderen Paket-Registries und Werkzeugen genutzt wird. Es ist nicht die einzige Art, Software zu versionieren - manche Projekte verwenden kalenderbasierte Versionierung (wie 2026.07) oder ihr eigenes Schema - aber SemVer ist am weitesten verbreitet verstanden, und es zu kennen macht das Lesen von Changelogs und Abhaengigkeitsbereichen weit einfacher.

Die praktische Erkenntnis: lies eine Version wie einen Satz. Ein Sprung in der ersten Zahl sagt: anhalten und vor dem Upgrade auf brechende Aenderungen pruefen. Ein Sprung in der zweiten sagt, dass es neue Funktionen gibt, aber dein bestehender Code sicher ist. Ein Sprung in der dritten sagt, dass es eine sichere Fehlerbehebung ist. Diese eine Gewohnheit - die Position zu lesen, die sich geaendert hat - verwandelt eine undurchsichtige Zahl in eine klare Botschaft ueber Risiko.