EMZETT.
Login

Semantische Versionierung (SemVer) und Versionsnummern

Kurz: SemVer nummeriert Versionen als MAJOR.MINOR.PATCH: Major bei inkompatiblen Änderungen, Minor bei neuen kompatiblen Funktionen, Patch bei Fehlerkorrekturen.

Genauer: Eine Versionsnummer soll Erwartungen wecken: Kann ich gefahrlos aktualisieren? Semantic Versioning 2.0 (semver.org) gibt dafür klare Regeln.

Im Detail

Das Schema

MAJOR.MINOR.PATCH, z. B. 2.4.1:

  • PATCH (2.4.1 → 2.4.2): rückwärtskompatible Fehlerkorrekturen.
  • MINOR (2.4.2 → 2.5.0): neue Funktionen, abwärtskompatibel; Patch zurück auf 0.
  • MAJOR (2.5.0 → 3.0.0): inkompatible Änderungen (Breaking Changes); Minor/Patch zurück auf 0. Vorab-Versionen: 3.0.0-beta.1, -rc.2; Build-Metadaten: 1.0.0+20260101. 0.y.z gilt als instabil: alles kann brechen. Die erste stabile Version ist 1.0.0.

Versionsbereiche (npm, Python & Co.)

  • ^1.4.2 (npm): kompatibel, erlaubt 1.x.x ab 1.4.2 (nicht 2.0.0).
  • ~1.4.2: nur Patch-Updates (1.4.x).
  • 1.4.2: exakt.
  • >=1.2 <2: Bereich.
  • Python: ~=1.4.2 (kompatibel), ==, >=. Dazu Lockfiles, damit Builds reproduzierbar bleiben. npm outdated, npm update, Renovate/Dependabot halten Abhängigkeiten aktuell; Major-Updates lesen (Changelog/Migrationsguide) und in Ruhe testen.

Wann ist es ein Breaking Change?

Entfernte/umbenannte Funktionen oder Parameter, geänderte Rückgabewerte, andere Fehler/Exceptions, strengere Validierung, geänderte Standardwerte, höhere Mindestversionen (Node, Python), Wegfall von Plattformen, geänderte API-Antwortformate, Datenbank-Schemaänderungen. Alles, worauf sich Nutzer verlassen können, ist Teil der öffentlichen Schnittstelle. Lieber erst deprecaten (Warnung, Übergangszeit), dann im nächsten Major entfernen.

Alternativen und Praxis

  • CalVer (2026.10, Ubuntu 24.04): zeitbasiert, passend für Anwendungen/Releases im Rhythmus.
  • Build-/Commit-Hashes für Deployments.
  • Conventional Commits (feat:, fix:, feat!:) ermöglichen automatische Versionsvergabe und Changelogs (semantic-release, release-please).
  • Git-Tags v1.2.3, Release-Notes mit Migrationshinweisen.
  • Für Web-APIs: Version in URL/Header (siehe API-Versionierung); Apps zeigen Version im „Über“-Dialog (Support!).
  • Konsistent bleiben: lieber ein einfaches Schema verlässlich nutzen als ein kompliziertes oft brechen.

Siehe auch: Git-Tags, Releases und Changelog, API-Versionierung