Wie versioniert man richtig?

Versionsnummern dienen bekanntlich in der Softwareentwicklung zur Kennzeichnung und Unterscheidung von Programmen und deren Entwicklungsstände.

Fast immer wird eine mehrgliedrige Versionierung eingesetzt, aber wann wird welche Nummer hochgesetz, und was für unterschiedliche Strategien gibt es dabei?

In der professionellen Softwareentwicklung wird häufig eine viergliedrige Versionsnummer nach dem Schema A.B.C.D (Beispiel 1.0.2.13) verwendet.

Aber leider kocht bei den Bezeichnungen und den Bedeutungen dieser vier Nummern mal wieder jeder sein eigenes Süppchen, was durchaus zu Verwechslungen führen kann.

Bezeichnungen

Schaut man nämlich bei Wikipedia nach, dann lauten die Bezeichnungen dieser vier Nummern:

<Hauptversion><Nebenversion><Revisionsnummer><Buildnummer>

beziehungsweise auf englisch:

<major release><minor release><patch level><build number>

Microsoft wiederum hat seine eigenen Bezeichnungen, und so heisst es dort

<major version><minor version><build number><revision>

Was ist jetzt richtig?

Bedeutungen

In beiden oberen Fällen ist die Bedeutung der Haupt- und Nebenversion eindeutig.

So bedeutet das Hochsetzen der Hauptnummer eine große Veränderung in der Software, die Nebenversion kennzeichnet ein wichtige funktionale Erweiterung, aber nicht so eingreifend wie die bei der Hauptversion.

Bei den letzten beiden Nummern wird nun in der Deutung unterschieden.

So bedeutet nach Wikipedia Benahmung die dritte Nummer (also Revision)  meist eine Fehlerbehebung und die vierte, die Buildnumber, die Anzahl der Kompilierungen, die bisher durchgeführt wurden.

Diese wird also bei jedem Kompilieren um eins erhöht.

Bei der Windows Kennzeichnung bedeutet Nummer drei (Build) eine kleinere Erweiterung, während durch die vierte Versionsnummer, der Revision, Fehlerbehebungen gekennzeichnet werden.

Wann allerdings in beiden Versionen untere Versionen auf „0“ zurückgesetzt werden, ist in Unternehmen völlig unterschiedlich.

So wird in vielen Unternehmen kleinere Version sofort zurückgesetzt, sobald eine höhere Versionsnummer hochgezählt wird (2.1.4.10, 3.0.0.0).

Andere zählen bestimmte Nummern wiederum gnadenlos weiter hoch (2.1.4.10, 3.0.5.0). Auch wenn sich dies merkwürdig anhört, so wird dies häufig, wegen einer besseren firmeninternen Verwaltung getan.

Andere Versionsnummern

Es gibt natürlich auch noch andere Versionierungssysteme, wie zum Beispiel ein-, zwei- oder auch dreigliedrige Versionsnummern.

Ein intessantes Beispiel ist das Bloggersystem von WordPress: WordPress kommunizierte nämlich nach außen ein Zwei-Nummernsystem (intern können durchaus noch weitere Nummern existieren), obwohl es wie ein Drei-Nummernsystem aussieht.

So besteht die Major-Version aus den ersten beiden Nummern (2.6, 2.7, 2.8,…) während der Dritte Bug-Fixes und kleine Änderungen darstellt (2.7.1,2.7.2,…).

Durch die erste Zahl wird also nichts besonderes dargestellt, vielmehr wird sie automatisch hochgezählt, wenn eine zweistellige Versionsnummer käme (2.10 wird zu 3.0).

Fazit

Im Endeffekt bleibt es jedem Entwickler selbst überlassen, wie er die Versionen verwaltet und sie hochzählt.

Nur sollte man sich auf jedenfall ein Regelsystem aufbauen, an dem zu erkennen ist, wann welche Nummern zu ändern sind und was sie aussagen.

Schließlich geht es ja hierbei darum bei den vielen Versionen einer Software , die im Laufe der Zeit entstehen und den Kunden ausgeliefert werden, die Übersicht zu behalten.

Mir persönlich gefällt die Microsoft-Variante am besten, außerdem halte ich sie und für am praxisorientiertesten.

Allerdings werden bei uns im Gegensatz zu MS die unteren Versionen auf „0“ zurück, wenn eine obere Nummer hochgesetzt wurde.

Aber was ist Eure Meinung dazu? Wie versioniert Ihr Eure Programme bzw. wie wird es in Eurem Unternehmen gemacht?

Oder haltet Ihr dies nur für große Unternehmen sinnvoll und für kleinere als für überflüssig?