Versionsnummer

Versionsnummern unterscheiden einzelne Versionen einer Software um die Ergebnisse sich anreihender Entwicklungszyklen gegeneinander abzugrenzen.

Die Versionsnummer ist die Grundlage für die Versionsverwaltung. Den Prozess der Vergabe der Versionsnummer nennt man Versionierung.

Aufbau und Bedeutung

Eine klassische Versionsnummer setzt sich häufig zusammen:

Hauptversionsnummer

(englisch: major release) indiziert meist äußerst signifikante Änderung am Programm – zum Beispiel wenn das Programm komplett neu geschrieben wurde (zum Beispiel GIMP 1.x nach 2.x) oder sich bei Bibliotheken keine Schnittstellenkompatiblität aufrechterhalten lässt.

Nebenversionsnummer

(englisch: minor release) bezeichnet meistens die funktionelle Erweiterung des Programms.

Revisionsnummer

(englisch: patch level) enthält meist Fehlerbehebungen.

Buildnummer

(englisch: build number) kennzeichnet in der Regel den Fortschritt der Entwicklungsarbeit in Einzelschritten, wird also zum Beispiel bei 0001 beginnend mit jedem Kompilieren des Codes um eins erhöht. Version 5.0.0-3242 stünde also für das 3242. Kompilationsprodukt einer Software. Verwendet man Versionskontrollsysteme, so wird an Stelle der Build-Nummer gerne eine Nummer verwendet, die die Quellen zum Kompilat innerhalb des Versionskontrollsystems eindeutig identifiziert. Das erleichtert bei Vorkommen eines Bugs die betreffenden Quellen zu finden.

Beispiel für die 2. Version eines Programms, in der 3. Nebenversion und in der 5. Fehlerkorrektur, Build 0041:

2.3.5-0041
│ │ │  └────── Buildnummer
│ │ └───────── Revisionsnummer
│ └─────────── Nebenversionsnummer
└───────────── Hauptversionsnummer

Jede dieser Versionsnummern kann auch aus mehreren Ziffern bestehen. Zum Beispiel folgt nach Version 0.9, wenn sich nur die Nebenversion erhöht, 0.10 und nicht 1.0. Bei manchen Programmen ist daher die Nebenversionsnummer zweistellig oder enthält eine führende Null wenn mit mehr als zehn Versionen dieser Art zu rechnen ist (Beispiel: 0.09).

Grundsätzlich gibt es für die Bedeutung der einzelnen Werte jedoch keine festen Vorgaben, vielmehr haben sich Quasi-Standards etabliert: Unter .NET folgt man z. B. dem gegenüber abweichenden Schema <Hauptversionsnummer>.<Nebenversionsnummer>.<Buildnummer>.<Revisionsnummer>^[1] (vertauschte Position für Revisionsnummer und Buildnummer).

Zu einem Versionsstand an einem beliebigen Zeitpunkt sagt man auch Build. Die Build-Nummer wird in vielen Projekten unabhängig von den anderen Nummern erhöht und nicht zurückgesetzt. Zum Beispiel gibt es bei Microsoft Windows zwei Produktreihen: in der Reihe Windows 95 sind die Builds 950 (Windows 95) und 2222 (Windows 98 SE) bekannt, in der Reihe Windows NT sind dies die Builds 1381 (Windows NT 4.0 Service Pack 6), 2600 (Windows XP), 6000 (Windows Vista) und 7600 (Windows 7).

Oftmals ist es – vor allem bei Open-Source-Software – der Fall, dass sich die Versionsnummern von Programmen oder Systemen noch vor der Version 1.x befinden. Dies deutet jedoch nicht zwingend darauf hin, dass die Entwicklung noch nicht weit fortgeschritten ist, sondern eher, dass die Version noch nicht das von den Entwicklern gesteckte Ziel erreicht hat und sich weiterhin in der Entwicklung befindet. Teilweise gibt es sogar Open-Source-Programme, die - obwohl sie den Alpha- und Beta-Status längst verlassen haben - weiterhin noch unterhalb der Version 1.0 versioniert sind.

Eine Versionsnummer wird oft nach dem Programmnamen angeführt und manchmal durch „v.“ oder „V“ (für Version) speziell gekennzeichnet.

Marketingaspekte

Für die Software-Entwicklung stellen Versionsnummern eine weitaus wichtigere Information als für den Kunden dar. Mit Hilfe der Versionsnummern kann unter anderem sichergestellt werden, dass in Entwicklergruppen neue Programmteile nicht mit älteren überschrieben werden. (siehe Versionsverwaltung).

In größeren Softwareprojekten wird unter Umständen aus Marketingaspekten von der internen, eher technisch motivierten Versionierung abgewichen, was dann zu Versionsnamen führt („Windows XP“ entspricht beispielsweise „Windows NT 5.1“), aus denen sich die Versionsfolge nicht mehr ohne weiteres erkennen lässt. Aus Marketinggründen kann es auch zum Überspringen von Versionsnummern kommen, um keine niedrigere Version (welche als „älter“ interpretiert werden kann) als Mitwettbewerber zu haben. Dies war beispielsweise bei WinWord, dessen Version von 2.0 auf 6.0 sprang, und Slackware der Fall. Auch bei verschiedener Software vom gleichen Hersteller kann es ähnliche Fälle geben, so wurde z. B. die erste Version von Windows NT Windows NT 3.1 genannt, da sie nach Windows 3.1 auf den Markt kam. Bei „Windows 7“ wurde von der internen Versionsnummer („Windows NT 6.1“) aus technischen und psychologischen Gründen abgewichen.

Auch werden andere Arten, Programmversionen voneinander zu unterscheiden, verwendet, da sie leichter zu merken sind:

• Jahreszahlen, zum Beispiel: Windows 95;
• alphanumerische Bezeichner, zum Beispiel: Adobe Photoshop CS2, Adobe Flash MX;
• Codenamen, zum Beispiel: Mac OS X Tiger;
• Jahre und Monate; so wird zum Beispiel die Versionsnummer der Ubuntu-Distribution aus der letzten Ziffer der Jahreszahl und dem Monat des Erscheinens gebildet. Zum Beispiel Ubuntu 6.04 (für 2006.04 = April 2006).
• Die Versionsnummer von TeX nähert sich π an; die von METAFONT der Eulerschen Zahl e.

Ergänzungen

Logo einer Beta-Version

Je nach Entwicklungsstadium der Software gibt es noch Ergänzungen:

Alpha

während der Entwicklung der Software, sehr frühes Stadium

Beta

zum Testen vorgesehen, begrenzter Anwenderkreis

RC

Veröffentlichungskandidat (release candidate rc), abschließende Testversion

Release (final)

endgültige Version

Patch

auch patchlevel pl – Korrekturlevel

Einzelnachweise

1. ↑ Versionsnummern in .NET (englisch)

Weblinks

• http://semver.org/ Semantic Versioning Specification (SemVer) (englisch)