Was bedeutet 0.1.0? Versionierung in der Softwareentwicklung: SemVer, CalVer und ZeroVer erklärt

Wenn du eine package.json, Cargo.toml oder pyproject.toml öffnest und Versionsnummern wie 1.4.2, 0.1.0 oder 24.04 siehst, hält man sie leicht für beliebige Labels, die der Maintainer sich ausgesucht hat.

In Wahrheit ist eine Versionsnummer ein formaler Vertrag zwischen dem Autor einer Bibliothek und jedem Produktivsystem, das davon abhängt. Diesen Vertrag misszuverstehen ist einer der schnellsten Wege, eine laufende Anwendung mit einem einzigen npm update lahmzulegen.

Gehen wir die vier gängigsten Versionierungsphilosophien der modernen Softwareentwicklung durch.

1. SemVer (Semantic Versioning): MAJOR.MINOR.PATCH

SemVer wurde von Tom Preston-Werner (Mitgründer von GitHub) entwickelt und in der Spezifikation SemVer 2.0.0 formalisiert. Semantic Versioning wird von etwa 90 % der Open-Source-Bibliotheken verwendet.

Jedes Release folgt einem strikten dreiteiligen Format: MAJOR.MINOR.PATCH (zum Beispiel 2.4.1).

   2   .   4   .   1
   │       │       └── PATCH: Backward-compatible bug fixes & security patches
   │       └────────── MINOR: Backward-compatible new features
   └────────────────── MAJOR: Breaking changes (Incompatible API modifications)

So funktioniert jede Erhöhung

• PATCH (2.4.1 ➔ 2.4.2): Nur interne Bugfixes, Performance-Optimierungen oder Sicherheits-Patches. Es werden keine neuen öffentlichen Methoden hinzugefügt, und bestehender Code funktioniert garantiert weiter.
• MINOR (2.4.2 ➔ 2.5.0): Fügt neue Funktionalität abwärtskompatibel hinzu (oder markiert eine alte Methode als @deprecated, ohne sie zu entfernen). Beachte, dass eine Erhöhung von MINOR den PATCH-Zähler auf 0 zurücksetzt.
• MAJOR (2.5.0 ➔ 3.0.0): Kennzeichnet einen Breaking Change. Funktionssignaturen haben sich geändert, Parameter wurden entfernt oder Rückgabetypen verändert. Für ein Upgrade über eine MAJOR-Version hinweg musst du den Migrationsleitfaden lesen und den Code deiner Anwendung anpassen.

2. ZeroVer (0.x.x): Die ewige Beta-Warnung

Was bedeutet 0.1.0 oder 0.24.3 eigentlich?

Laut Regel 4 der offiziellen SemVer-2.0.0-Spezifikation:

„Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.“

In einer 0.x.x-Bibliothek (oft augenzwinkernd ZeroVer genannt) verschieben sich die üblichen Regeln in der Praxis um eine Stelle: Maintainer führen häufig Breaking Changes in einem Minor-Sprung von 0.1.0 ➔ 0.2.0 ein.

3. CalVer (Calendar Versioning): Zeitgesteuerte Releases

Nicht jedes Projekt passt sauber in SemVer. Betriebssysteme, Browser und große Entwicklerplattformen entwickeln sich kontinuierlich weiter, statt sich um einen einzelnen API-Vertrag zu drehen. Diese Projekte verwenden CalVer (YYYY.MM oder YY.0M.MICRO).

• Ubuntu Linux: 24.04 LTS bedeutet buchstäblich April 2024. Du weißt sofort, wann das Betriebssystem erschienen ist und wann das 5-jährige Supportfenster endet.
• JetBrains-IDEs: 2026.2 steht für das zweite große Release des Jahres 2026.
• pip & Certbot: Nutzen kalenderbasierte YY.M-Releases, damit man auf einen Blick sieht, wie alt ein Deployment-Tool ist.

4. Versionierung per Git-Commit-SHA (CI/CD & Microservices)

Wenn du eine interne Webanwendung oder einen Microservice baust, der 15-mal am Tag per GitHub Actions deployt wird, ist es sinnlose Bürokratie, 1.0.14 von Hand auf 1.0.15 zu erhöhen.

Moderne DevOps-Pipelines taggen Docker-Images und Sentry-Releases direkt mit dem unveränderlichen Git-Commit-Short-SHA oder einer Mischform mit Zeitstempel:

# Tagging a production container image with Date + Git Commit SHA
GIT_SHA=$(git rev-parse --short HEAD)
IMAGE_TAG="2026.10.25-${GIT_SHA}"
docker build -t registry.czay.dev/api:${IMAGE_TAG} .

Wenn um 03:00 Uhr nachts in Production eine Exception auftritt, musst du nicht raten, worauf v1.4.9 zeigt – du führst git show a4b8c1f aus und siehst sofort den genauen Commit.

Entscheidungsmatrix im Überblick