Versionsnummer

Grundidee und Zweck

Versionsnummern unterscheiden verschiedene Versionen einer Software und machen ihre Weiterentwicklung nachvollziehbar. Die Vergabe solcher Nummern heißt Versionierung. Versionsnummern bilden damit eine Grundlage der Versionsverwaltung, mit der Entwicklungsstände organisiert und Änderungen zwischen Versionen verfolgt werden können. Eine Versionsnummer steht häufig nach dem Programmnamen und wird manchmal durch „v.“, „v“ oder „V“ gekennzeichnet.

Die Bedeutung der einzelnen Bestandteile ist allerdings nicht allgemein verbindlich festgelegt. Es haben sich vor allem Quasi-Standards herausgebildet, die je nach Programm oder Entwicklungsumgebung unterschiedlich verwendet werden.

Semantisches Schema

Eine häufige Form der Versionsnummer besteht aus Hauptversionsnummer, Nebenversionsnummer, Revisionsnummer und Buildnummer.

• Die Hauptversionsnummer (major release) weist meist auf eine äußerst bedeutende Änderung hin. Das kann beispielsweise eine vollständige Neuentwicklung des Programms sein, wie bei GIMP 2.x nach 1.x, oder der Verlust der Schnittstellenkompatibilität bei einer Bibliothek.
• Die Nebenversionsnummer (minor release) bezeichnet meistens eine funktionale Erweiterung.
• Die Revisionsnummer (patch level oder micro release) steht meist für Fehlerbehebungen.
• Die Buildnummer (build number) kennzeichnet den Fortschritt der Entwicklungsarbeit in einzelnen Schritten. Sie kann bei 0001 beginnen und bei jedem Kompilieren um eins steigen. Version 5.0.0-3242 wäre dann das 3242. Kompilationsprodukt. Bei Verwendung eines Versionskontrollsystems kann die Buildnummer auch eine Kennung sein, die die verwendeten Quellen eindeutig identifiziert.

Ein Beispiel ist 2.3.5-0041: Hauptversion 2, Nebenversion 3, Revision 5 und Build 0041.

Jede Stelle kann aus mehreren Ziffern bestehen. Nach 0.9 folgt bei einer Erhöhung nur der Nebenversion 0.10 und nicht 1.0. Deshalb können Nebenversionsnummern zweistellig sein oder eine führende Null enthalten, etwa 0.09. Wird die Haupt- oder Nebenversionsnummer erhöht, werden die folgenden Stellen außer der Buildnummer auf 0 gesetzt. Auf 2.3.5 folgen daher je nach Änderungsumfang 2.3.6, 2.4.0 oder 3.0 beziehungsweise 3.0.0. Bei Hauptversion 0 sind größere Änderungen trotz einer Erhöhung der Nebenversion häufig möglich.

Ein abweichendes Schema verwendet das .NET-Framework: Dort lautet die Reihenfolge Hauptversionsnummer.Nebenversionsnummer.Buildnummer.Revisionsnummer, sodass Build- und Revisionsnummer gegenüber dem obigen Beispiel vertauscht sind. Außerdem unterscheidet .NET mehrere Versionstypen: Die AssemblyFileVersion bezeichnet einen individuellen Build und wird auch bei identischem Quelltext erhöht, wenn eine neue Assembly erstellt wird. Die AssemblyInformationalVersion bezeichnet die Version eines Produkts aus mehreren Assemblies. Die AssemblyVersion bezeichnet die Version einer Assembly und bleibt bei Erstellung aus identischem Quelltext gleich.

Ein Versionsstand zu einem bestimmten Zeitpunkt wird ebenfalls Build genannt. Buildnummern werden in vielen Projekten unabhängig von den übrigen Nummern erhöht und nicht zurückgesetzt. Beispiele aus Windows sind in der Windows-9x-Reihe die Builds 950 für Windows 95, 1998 für Windows 98 und 2222 für Windows 98 SE. In der Windows-NT-Reihe sind unter anderem 1381 für Windows NT 4.0 Service Pack 6, 2600 für Windows XP, 6000 für Windows Vista, 7600 für Windows 7, 9200 für Windows 8 und 9600 für Windows 8.1 bekannt. Seit Windows 10 besitzt jede Version eine eigene Buildnummer.

Versionsnummern unterhalb von 1.x bedeuten besonders bei Open-Source-Software nicht zwingend, dass die Entwicklung noch wenig fortgeschritten ist. Häufig ist damit gemeint, dass das von den Entwicklern gesetzte Ziel noch nicht erreicht wurde. Manche Programme bleiben auch nach dem Ende von Alpha- und Beta-Phase unterhalb von 1.0.

Versionsnummern mit Datum

Eine Alternative zur klassischen Nummerierung ist eine Versionsnummer, die ein Datum enthält. Das Beispiel 2024.10.12-0002 setzt sich aus dem Jahr 2024, dem Monat 10, dem Tag 12 und der Buildnummer 0002 innerhalb dieses Tages zusammen. Die Reihenfolge ist somit Jahr.Monat.Tag-Buildnummer.

Marketing und alternative Bezeichnungen

Für die Softwareentwicklung sind Versionsnummern meist wichtiger als für Kunden. In Entwicklergruppen helfen sie beispielsweise dabei, neue Programmteile zu verwalten und zu verhindern, dass sie ältere Teile überschreiben.

In großen Projekten kann die öffentlich verwendete Bezeichnung aus Marketinggründen von der technisch motivierten internen Versionierung abweichen. So entspricht Windows XP intern „Windows NT 5.1“. Versionsnummern können auch übersprungen werden, damit ein Produkt nicht durch eine niedrigere Nummer als älter als ein Mitbewerber erscheint. Beispiele sind WinWord, dessen Nummer von 2.0 auf 6.0 sprang, sowie Slackware und Windows 10. Windows NT 3.1 wurde nach Windows 3.1 benannt, weil es danach auf den Markt kam und dieselbe grafische Oberfläche verwendete. Bei Windows 7 wich man aus technischen und psychologischen Gründen von der internen Nummer „Windows NT 6.1“ ab; außerdem wurde „Windows 9“ als Produktname übersprungen, ebenso die NT-Versionen 7 bis 9.

Zur leichteren Einprägsamkeit werden auch andere Bezeichnungen verwendet:

• zweistellige Jahreszahlen wie Windows 95 und Microsoft Office 95;
• vierstellige Jahreszahlen wie Windows 2000, Microsoft Office 2000 und SoftMaker Office 2006;
• Jahr und Monat, etwa Ubuntu-Linux 6.04 für April 2006, OPNsense 15.1 für Januar 2015 oder Windows 10 1507 für Juli 2015;
• Jahr und Halbjahr, etwa Windows 10 20H2 für das 2. Halbjahr 2020;
• alphanumerische Bezeichnungen wie Adobe Photoshop CS2, Adobe Flash MX und Windows XP;
• Codenamen wie Mac OS X Panther, das seit 2016 macOS heißt, oder Windows Vista;
• systematische Codenamen. Ubuntu kombiniert die Versionsnummer mit „Adjektiv + Tiername“ und verschiebt bei jeder neuen Version den Anfangsbuchstaben um eine Stelle im Alphabet. Auf „Bionic Beaver“ folgte „Cosmic Cuttlefish“.

Bei manchen Programmen folgen die Nummern besonderen Regeln. Die Versionsnummer von TeX nähert sich π an, die von Metafont der Eulerschen Zahl e. Beim Linux-Kernel hat die Versionsnummer ab 2.6 keinen Zusammenhang mit tatsächlichen Fortschritten. Bei GIMP kennzeichnet eine gerade zweite Ziffer, etwa in 2.2, 2.4 oder 2.6, eine stabile Version; Entwicklerversionen haben dort eine ungerade zweite Ziffer. Dieses Prinzip wurde auch beim Linux-Kernel von 2.0 bis 2.6 verwendet: Die Entwicklerversionen waren 2.1, 2.3 und 2.5.

Ergänzungen nach Entwicklungsstand

Zusätzlich zur Versionsnummer können Angaben zum Entwicklungs- und Veröffentlichungsstatus verwendet werden:

• Alpha: sehr frühes Stadium während der Entwicklung.
• Beta: zum Testen vorgesehene Version für einen begrenzten Anwenderkreis.
• RC: „release candidate“, also ein Veröffentlichungskandidat und eine abschließende Testversion.
• Release oder final: die endgültige Version, wobei „Release“ für Veröffentlichung steht.
• Patch, auch patchlevel oder pl beziehungsweise deutsch Korrekturlevel: eine Ergänzung zur Kennzeichnung von Korrekturen.