Konkret

Da hat sich im Blog nebenan mein Kollege Golo Roden die Mühe gemacht, ein allgegenwärtiges Problem in der Softwareentwicklung zu thematisieren: Versionsnummern. Das ist zunächst einmal in zweierlei Hinsicht nichts Besonderes. Zum einen weil er sich schließlich ausgesucht hat, hier zu bloggen. Und zum anderen scheint auch das Thema selbst nicht so prickelnd, hat doch jeder schon einmal davon gehört und benutzt es vielleicht schon seit Jahren selbst.

Der mit Versionsnummern richtig vergeben überschriebene Artikel berichtete über Semantic Versioning und gab eine übersichtliche Zusammenfassung darüber, wie man in diesem Sinne Versionsnummern vergeben kann und welche Bedeutung dies für das versionierte Artefakt hat.

Was mich ein bisschen verwundert hat, waren die diesbezüglichen Kommentare. So fragte sich einer, was denn neu daran sei. Ein anderer bezweifelte den Nutzwert des Artikels und fragte, ob es echt Entwickler gäbe, denen sich so etwas Triviales wie Major.Minor.Patchlevel nicht erschließe. Und noch ein anderer schließlich glaubt, Versionierung sei ein Problem von JavaScript und möchte deshalb einen großen Bogen darum machen.

Mal ganz abgesehen davon, dass die nicht selten von Polemik triefenden Kommentare auch noch am Thema vorbeigehen, übersehen diese oft einen ganz wichtigen Aspekt, nämlich dass jeder für sich genommen in der Regel machen kann, was er will. Das bezieht sich gleichermaßen auf die Rechtschreibung, das Fahrverhalten wie auf die Versionierung. Sobald man sich aber in einer Gruppe beliebiger Größe n bewegt (n > 1), gilt das nicht mehr.

Bezüglich der Rechtschreibung ergibt sich das Problem beispielsweise schon dann, wenn man auf Groß- und Kleinschreibung verzichtet. Der Satz "ich habe in moskau liebe genossen" lässt etwa keine konkreten Schlüsse darüber zu, welchen Aktivitäten der Schreiber in Moskau nachgegangen ist. Das soll nicht heißen, dass auch bei korrekter Schreibweise keine Mehrdeutigkeiten möglich sind (wie auch immer korrekt definiert sein mag: nach Duden, nach Wahrig, nach dem jeweiligen Deutschlehrer oder womöglich nach Bastian Sick).

Staubecken etwa sind Staub-Ecken oder Stau-Becken, was sich nur durch den Kontext oder Bindestriche erschließen lässt. Aber man muss es gar nicht so kompliziert machen, denn schließlich gibt es in unserer Sprache genügend Teekesselchen, die ohne ausreichenden Kontext durchaus zur Verwirrung führen können: Bank oder – um in unserer Branche zu bleiben – Instanz.

Gerade wegen dieser vielen Möglichkeiten ist es für uns von unschätzbarem Wert, dass sich jemand die Mühe gemacht hat, für einen eingeschränkten Anwendungsbereich die Art der Versionierung genau zu spezifizieren und dem auch noch einen brauchbaren Namen zu geben. Mit Hilfe dieses Vorgehens ist es also möglich – vorausgesetzt, dass die Spezifikation richtig umsetzt wurde –, vorhersagbare und verlässliche Ergebnisse zu erzielen.

Das heißt, dass die Versionsnummern 1.1.2, 1.2.3 und 2.0.1 einer Bibliothek im Zusammenhang mit dem Semantic Versioning eine wohldefinierte Ordnung haben. Ein Anwendung, die auf Version 1.1.2 dieser Bibliothek angewiesen ist, wird damit – wenn man mal von neu eingebauten Fehlern absieht – sicher auch mit Version 1.1.3 laufen können. Version 2.0.1 mag zwar mit neuen Funktionen locken, ist aber (leider) sicher nicht kompatibel.

Darüber hinaus legt dieser Standard fest, das nach 1.0.0-alpha die Version 1.0.0-beta und danach die Version 1.0.0 kommt. Das Versionierungsschema hat aber keine Vorstellung von griechischen Suffixen, sondern sortiert einfach nach den ASCII-Codes. Das bedeutet, dass nach beta das Suffix delta käme und nicht etwa gamma, was der korrekten griechischen Folge entspräche. Dies ist also nicht notwendig clever, aber eben eindeutig! Wobei das insofern entschuldbar ist, weil es in der Praxis anscheinend keine gamma- und delta-Versionen gibt.

Zusammenfassend gibt es zu sagen:

1. Grundsätzlich darf jeder machen, was er will.
2. Wenn man etwas machen will, was auch andere verstehen sollen, dann bezieht man sich besser auf etwas, das einen Namen und eine Version hat, und gibt dann auch beides an.

Letzteres hat den Vorteil, dass man auf etwas Konkretes Bezug nehmen und sich (in der Regel) auch darauf verlassen kann. Bei der GNU General Public License (GPL) etwa muss man den ganzen Text nicht mehr lesen, weil dieser schon in aller Ausführlichkeit besprochen und kommentiert wurde. Man muss lediglich wissen, ob es sich um die Version 2 oder 3 handelt. Das gilt analog auch für die Creative Commons (wenngleich viele der auf diese Weise annotierten Artefakte, für deren Nutzung eine Namensnennung gefordert wird, nicht spezifizieren, *welcher* Name angegeben werden soll).

Das grundsätzlich Klärungsbedarf bei noch so selbstverständlichen Dingen existiert, zeigt RFC 2119. In dem Dokument wird beschrieben, wie die Wörter der Art muss, soll, kann, optional und erforderlich als Schlüsselwörter bei einer Implementierung einer Spezifikation zu interpretieren sind. Darüber hinaus definiert es sogar, wie zu deklarieren ist, dass diese Wörter eine genau definierte Bedeutung haben:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Ein derartiger Bezug macht also erst die Bedeutung eindeutig und konkret. Unabhängig davon, ob man die referenzierte Regelung verstanden hat oder nicht, dient diese im Zweifelsfall zusätzlich als unumstößliche Entscheidungsgrundlage. Damit kann eindeutig entschieden werden, wer einen etwaigen Nachbesserungsaufwand hat.

Ich für meinen Teil bin auf jeden Fall dankbar um den Blog-Eintrag von Golo, weil ich auf diese Weise wieder einmal auf etwas aufmerksam gemacht worden bin, das mir bei meiner Arbeit konkret (!) weiter hilft und mir erspart, für bestimmte Anwendungsfälle das Rad neu zu erfinden. ()