Dritter Anlauf: Über Versionsnummern. Wie jedem schnell klar wird, der in einem größeren Softwareprojekt mit Versionsnummern zu tun hatte, ist das Thema kompliziert. In erster Linie, weil man schnell übersehen kann, daß ein einzelnes Stück Software viele Versionsnummern hat.
Da wäre zunächst einmal die Produktversion. Das ist die Bezeichnung, die draußen draufsteht. Wenn Microsoft ein Windows 7 verkauft, heißt das nicht, daß es sieben Versionen von Windows gibt. Vielmehr heißt es, Microsoft eine "Aggregation" aus Softwarekomponenten unter dem Namen "7" verkauft, die sich funktional von allen anderen Aggregationen unterscheidet. Entscheidend ist hier, daß 7 "anders" ist als beispielsweise Vista oder XP.
Eine Produktversion kann man eng oder lose definieren. Im Idealfall beschreibt eine Produktversion genau eine Kombination aus Komponentenversionen, aber das kommt letztlich darauf an, was Marketing und Rechtsabteilung draus macht. Wir haben uns mittlerweile an verwaschene Produktversionen gewöhnt, ja wir erwarten mittlerweile, daß eine Software regelmäßig kostenlos aktualisiert wird, womit Aussagen wie "Das ist ein nacktes Windows 7." an zwei unterschiedlichen Tagen zwei unterschiedliche Softwarestände beschreiben.
Technische Versionen sind da spezifischer: Sie beschreiben einen exakten Sachverhalt. Die Version 2.2.21 des Apache Webservers beispielsweise beschreibt einen exakten Stand von Quelltextversionen. Mit der Versionsnummer als Schlüssel läßt sich daraus jedes einzelne Zeichen in jeder einzelnen Zeile jeder einzelnen Datei der Software ableiten. ("Holistisch" klingt hier zwar gut, stimmt aber leider nicht. Trotzdem habe ich das Wort jetzt in meinem Artikel.) Je nachdem, wie sorgfältig die Entwickler bei der Festlegung der externen Abhängigkeiten waren, läßt sich auch die technische Version aller verwendeten Softwarepakete ableiten, obwohl die Schärfe der Definition aus praktischen Gründen an den Rändern immer weiter abnimmt.
Aber so vernünftig das auch klingt: Diese Versionsnummern werden willkürlich vergeben. Die Regeln zur exakten Bildung der Versionsnummer mögen strenger sein, aber im Grunde ist die Versionsnummer 2.2.21 nichts als ein einzelnes Symbol, ein Name, die einem spezifischen Quelltextstand bewußt zugeordnet wurde. Am besten paßt hier eigentlich die Bezeichnung "Release".
Anders die Buildnummern und die Versionsnummern einzelner Dateien im Source Code Management. Die Versionsnummern einzelner Dateien folgen keinem bewußten Willen, vielmehr klettern die Versionsnummern einiger Dateien schneller als die anderer. Teile des Codes bleiben jahrelang unberührt, andere werden im Minutentakt verändert. Die Versionen einer einzelnen Datei zu nummerieren hat keinen Wert und verleitet zu falschen Annahmen (weshalb sich verteilte SCMs das Leben leichter machen und es gleich ganz unterlassen, Versionen zu nummerieren). Buildnummern hingegen steigen kontinuierlich an, daher läßt sich aus zwei vorhandenen Nummern eine Reihenfolge der Builds ableiten. Nach wie vor ist es natürlich gefährlich, eine andere Bedeutung in diese Nummern zu interpretieren als die, daß Build 2 nach Build 1 ausgeführt wurde, insbesondere sind alle Annahmen zur Korrelation zwischen Nummer und Qualität unsinnig.
Wenn man über Versionsnummern spricht, muß man also wissen, was man damit meint. Benutzer von Software meinen, wenn sie von Versionen sprechen, oftmals die Produktversion, seltener eine technische Version ("Release"), normalerweise nicht die Buildnummer und praktisch nie die Dateiversion.
Es sollte klar sein, daß Produktversionen und technische Versionen sowie technische Versionen und Build- oder SCM-Versionen nur lose zusammenhängen und nicht synonym verwendet werden können. Wenn jetzt continuous builds auf traditionelle Testcenter treffen, wird die Sache spannend genug für einen eigenen Artikel.
