Semantic Versioning: was eine Versionsnummer verspricht

Worum es geht

Unter Semantic Versioning wird eine Version MAJOR.MINOR.PATCH wie folgt erhöht: MAJOR bei inkompatiblen API-Änderungen, MINOR bei abwärtskompatibler Funktionalität, PATCH bei abwärtskompatiblen Fehlerkorrekturen. Vorabversionen hängen einen Bindestrich und durch Punkte getrennte Kennungen an (1.0.0-alpha.1); Build-Metadaten hängen ein Pluszeichen an und werden bei der Bestimmung der Rangfolge ignoriert.

Warum es wichtig ist

Abhängige Projekte können ausdrücken, was sie akzeptieren ("jede 2.x"), weil die Zahl ein Versprechen trägt. Das Versprechen ist nur bedeutsam, wenn die Software eine öffentliche API deklariert; ohne diese Deklaration hat "inkompatible Änderung" keine festgelegte Bedeutung.

So wird es angewendet

• Die öffentliche API in der Dokumentation deklarieren: welche Module, Endpunkte, Felder, Kommandozeilen-Flags und Dateiformate abgedeckt sind.
• Die Hauptversion null (0.y.z) als "alles kann sich ändern" behandeln und dies auch so festhalten; die Spezifikation reserviert sie für die anfängliche Entwicklung.
• MAJOR erhöhen, wenn dokumentiertes Verhalten entfernt oder geändert wird, auch wenn die Änderung klein aussieht.
• Eine veröffentlichte Version nie nachträglich ändern; stattdessen eine neue veröffentlichen.

Stolpersteine

Eine Versionsnummer kann keine Verhaltenskompatibilität ausdrücken, die die API-Oberfläche nicht erfasst (Performance, Fehlertext, Reihenfolge). Veraltungshinweise in MINOR-Releases geben abhängigen Projekten Zeit vor einer MAJOR-Entfernung. Marketingversionen und semantische Versionen sind unterschiedliche Dinge und sollten nicht gezwungenermassen übereinstimmen.