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.zgilt als instabil: alles kann brechen. Die erste stabile Version ist1.0.0.
Versionsbereiche (npm, Python & Co.)
^1.4.2(npm): kompatibel, erlaubt1.x.xab 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, Ubuntu24.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