Erst vor wenigen Tagen wurde NPM Ziel eines Hacks, bei dem Angreifer manipulierte Versionen populärer Pakete veröffentlicht haben. Für die Personen, welche NPM Packages verwenden, kann eine Versionierung, ein Update etwa so ausehen: 2.5.13. Für Entwickler bedeutete das grosse Unsicherheit, welche Version habe ich installiert, und ist mein Projekt betroffen? Die Hintergründe und eine genauere Analyse findest du in meinem Artikel zum NPM Hack.

Dieser Vorfall hat mich dazu gebracht, genauer herauszufinden, was Versionsnummern eigentlich aussagen.

Bei meiner Recherche habe ich herausgefunde, dass Versionsnummern nicht zufällig gewählt werden. Sie sind ein Kommunikationssystem, eine Art Kurzsprache, mit der Entwickler signalisieren, was sich geändert hat, wie wichtig das Update ist und wie riskant es sein könnte.

Ich habe gemerkt, sobald man versteht, wie sie aufgebaut sind, sieht man Update-Benachrichtigungen mit ganz anderen Augen.

Der Standard: Semantische Versionierung (SemVer)

Die meisten modernen Projekte folgen der Semantischen Versionierung, Semantic Versioning, kurz SemVer, die so aussieht:

MAJOR.MINOR.PATCH

Nehmen wir meine breits genannte Versionierungsnummer 2.5.13 genauer unter die Lupe.

MAJOR (2)

  • Bedeutung: Ein grosser Sprung nach vorne, der oft nicht mehr kompatibel zu älteren Versionen ist.
  • Für Entwickler: APIs können sich ändern, alte Funktionen verschwinden oder Standardwerte verhalten sich anders.
  • Für Nutzer: Spürbare Änderungen – spannend, aber auch mit Risiken.

Ein klassisches Beispiel hier ist das neue OS von Apple. Immer wenn Apple ein klassisches „Major“-Update durchführt, gibt es neue Features und frisches Design, aber auch tagelange Arbeit, um Kompatibilitätsprobleme gelöst. Hier dauern die Updates bei mir immer etwas länger, und gewisse Apps funktionieren nicht mehr ganz korrekt.

MINOR (5)

  • Bedeutung: Neue Funktionen, die aber rückwärtskompatibel bleiben.
  • Für Entwickler: Man kann neue Möglichkeiten nutzen, ohne alten Code umschreiben zu müssen.
  • Für Nutzer: Verbesserungen sind spürbar, aber nichts bricht.

Eine klassisches Beispiel ist, wenn eine Python-Bibliothek neue Funktionen ergänzt. Oder eine App bekommt „Dark Mode“, während alles andere wie gewohnt bleibt.

PATCH (13)

  • Bedeutung: Kleine, sichere Korrekturen wie Bugfixes oder Performance-Optimierungen.
  • Für Entwickler: Keine neuen Features, nur Stabilität und Sicherheit.
  • Für Nutzer: Oft unauffällig, aber spürbar stabiler.

Sicherheitsupdates in Node.js sind klassisches Beispiel. Vergleichbar mit einem kleinen Rückruf beim Auto, nicht spektakulär, aber wichtig.

Pre-Release-Tags & Metadaten

Manchmal tauchen Zusatzbezeichnungen bei Versionsnummern auf.

  • 1.0.0-alpha → sehr früh, experimentell.
  • 1.0.0-beta → funktionskomplett, aber noch in Tests.
  • 1.0.0-rc.1 → „Release Candidate“, fast produktionsreif.
  • 1.0.0+build.456 → interne Build-Infos.

Für Entwickler

Diese Tags verhindern, dass instabiler Code versehentlich als stabil veröffentlicht wird. Diese Tags sind eine Art Warnhinweis.

Als Photoshop neu AI zur Bildbearbeitung getestet hat, habe ich zu beginn die Betaversion von Photoshop heruntergeladen, weil ich sehen wollte, wie gut das war und auch weil Photoshop nie wirklich mein Ass war. Die neue Funktion fand ich spannend, aber die App stürzte vermehrt ab und hat mich oft auch nicht richtig verstanden, so dass das generierte Bild entweder gar nicht das war, was ich haben wollte oder wenns dann geklappt hat wars so schlecht, dass jeder sah da wurde gepfuscht. Fazit: Beta heisst wirklich „wir sind am Testen“.

Andere Versionierungsarten

Nicht jedes Projekt hält sich an SemVer. Es gibt Alternativen:

  • Kalender-Versionierung (CalVer): Nutzt Jahres- und Monatszahlen.
    • Beispiel: Ubuntu 22.04 (April 2022).
  • Fortlaufende Nummerierung: Einfach v1, v2, v3.
    • Beispiel: Frühe Versionen von Photoshop.
  • Hybride Ansätze:
    • Der Linux-Kernel nutzte früher ungerade Versionsnummern für experimentelle Releases und gerade für stabile.
    • Manche Unternehmenssoftware mischt SemVer mit Kalenderdaten.

Die Wahl hängt davon ab, ob Einfachheit, Vorhersagbarkeit oder Kompatibilität im Vordergrund steht.

Warum Versionsnummern wichtig sind

  • Für Entwickler: Sie sind ein Signal. Patch = sicher, Minor = nützlich, Major = Vorsicht.
  • Für Nutzer: Sie zeigen Reife. Ein 0.x-Projekt ist meistens noch experimentell.
  • Für Teams: Sie verhindern das klassische „Bei mir läuft’s, bei dir nicht“, indem sie Abhängigkeiten klar kennzeichnen.

Fazit

Versionsnummern sind mehr als blosse Ziffern, sie sind eine Sprache der Veränderung.

Heute klicke ich nicht mehr gedankenlos auf „Update“. Ein kurzer Blick auf die Nummer genügt und ich weiss, ob das nur ein Fix, eine sichere Verbesserung oder ein grosser Sprung ist, auf den ich mich vorbereiten sollte?

Wer gelernt hat, diese Sprache zu lesen, erkennt sofort, ob ein Update ein kleiner Bugfix, eine willkommene Erweiterung oder ein Meilenstein ist, bei dem man lieber zweimal hinschaut.

Sehr gute Idee 👍 – so bietest du deinen Leser:innen direkt am Ende noch einen Mehrwert. Hier ein Vorschlag für einen abschließenden Abschnitt mit weiterführenden Links, passend zu deinem Artikel:

Weiterführende Artikel & Quellen

Falls du tiefer in das Thema einsteigen möchtest, findest du hier hilfreiche Ressourcen:

Zum Thema Sicherheit im npm-Ökosystem: