Softwareversionierung

Die Softwareversionierung ist der Prozess, eindeutigen Versionen von Computersoftware individuelle Versionsnamen oder -nummern zuzuweisen. Das am weitesten verbreitete Schema für Versionsnummern ist die semantische Versionierung ( SemVer ). Sie besteht aus einer dreiteiligen Versionsnummer (Hauptversion.Nebenversion.Patch), einem optionalen Vorabversionskennzeichen (z. B. Alpha, Beta) und einem optionalen Build-Meta-Tag. Eine vierte Zahl kann, wie beispielsweise bei Adobe Flash , den Software- Build kennzeichnen . Einige Unternehmen verwenden auch das Build-Datum (Kalenderversionierung) sowie Buchstaben und andere Zeichen, wie etwa Lotus 1-2-3 Release 1a.

Die meisten freien und Open-Source-Softwarepakete , einschließlich MediaWiki , verwenden Versionsnummern als fortlaufende Zahlenfolge, getrennt durch Punkte, z. B. 1.8.1, 1.9.0. Andere Softwarepakete hingegen verwenden Dezimalzahlen: 1.8, 1.81, 1.82. Entwickler können mehrere Nebenversionen auf einmal überspringen, um wichtige neue Funktionen anzuzeigen oder aus Marketinggründen. Versionsnummern dienen häufig dazu, Kopien eines Softwareprodukts zu identifizieren und sie in einem kollaborativen Versionskontrollsystem miteinander zu vergleichen.

In Softwareentwicklungsteams dient die Versionskontrolle dazu, inkrementell unterschiedliche Versionen von Informationen zu verwalten und Änderungen rückgängig machen zu können. Moderne Computersoftware wird häufig mithilfe zweier verschiedener Versionsverwaltungssysteme verwaltet: einer internen Versionsnummer, die sich mehrmals täglich ändern kann, und einer Release-Version, die sich in der Regel deutlich seltener ändert.

Historisch gesehen wurden Dateinummern insbesondere in der öffentlichen Verwaltung und in Unternehmen verwendet, um Dateien oder Fälle eindeutig zu identifizieren. Diese Praxis wurde erstmals mit dem ITS-Dateisystem des MIT und später dem TENEX- Dateisystem für die PDP-10 im Jahr 1972 in Computerdateien eingeführt. Im 21. Jahrhundert begannen immer mehr Programmierer, eine standardisierte Versionsrichtlinie zu verwenden, wie beispielsweise die semantische Versionierung ^{[ 1 ],} die sich insbesondere bei der Verwendung von Softwarebibliotheken , Frameworks und Kommandozeilenanwendungen als nützlich erweist.

Dateinummern wurden insbesondere in der öffentlichen Verwaltung sowie in Unternehmen verwendet, um Dateien oder Fälle eindeutig zu identifizieren. Für Computerdateien wurde diese Praxis erstmals mit dem ITS-Dateisystem des MIT eingeführt, später dem TENEX-Dateisystem für die PDP-10 im Jahr 1972. ^{[ 2 ]}

Später wurden Dateilisten mit ihren Versionen und Abhängigkeiten hinzugefügt. Linux-Distributionen wie Debian mit seinem dpkg entwickelten frühzeitig Paketverwaltungssysteme, die Abhängigkeiten zwischen ihren Paketen auflösen konnten. Debians erster Ansatz bestand darin, dass ein Paket die von ihm abhängigen Pakete kannte. Ab 1994 wurde dieses Prinzip umgekehrt: Ein Paket kannte nun die benötigten Pakete. Bei der Installation eines Pakets wurden mithilfe der Abhängigkeitsauflösung automatisch die benötigten Pakete berechnet und zusammen mit dem gewünschten Paket installiert. Um Aktualisierungen zu vereinfachen, wurden Mindestversionen für Pakete eingeführt. Daher musste das Nummerierungsschema angeben, welche Version neuer als die erforderliche war. ^{[ 3 ] [ 4 ] [ 5 ]}

Bei sequenzbasierten Softwareversionierungssystemen wird jeder Softwareversion eine eindeutige Kennung zugewiesen, die aus einer oder mehreren Zahlen- oder Buchstabenfolgen besteht. ^{[ 6 ]} Dies ist die einzige Gemeinsamkeit; die Systeme unterscheiden sich stark in Bereichen wie der Anzahl der Sequenzen, der Bedeutung einzelner Sequenzen und der Art und Weise, wie die Sequenzen inkrementiert werden.

In einigen Systemen werden sequenzbasierte Kennungen verwendet, um die Bedeutung von Änderungen zwischen Releases zu kennzeichnen. Änderungen werden nach ihrer Wichtigkeit klassifiziert, und die Entscheidung, welche Sequenz zwischen Releases geändert wird, basiert auf der Bedeutung der Änderungen gegenüber dem vorherigen Release. Dabei wird die erste Sequenz für die wichtigsten Änderungen geändert, und Änderungen an nachfolgenden Sequenzen repräsentieren Änderungen mit abnehmender Bedeutung.

Je nach Schema kann die Bedeutung anhand der geänderten Codezeilen, der hinzugefügten oder entfernten Funktionspunkte, der potenziellen Auswirkungen auf die Kunden hinsichtlich des erforderlichen Aufwands zur Einführung einer neuen Version, des Risikos von Fehlern oder nicht deklarierten inkompatiblen Änderungen, des Ausmaßes der Änderungen im visuellen Layout, der Anzahl neuer Funktionen oder praktisch allem, was die Produktentwickler oder Marketingfachleute als bedeutsam erachten, einschließlich des Marketingwunsches, die „relativen Vorteile“ der neuen Version hervorzuheben, beurteilt werden.

Semantische Versionierung (SemVer) ^{[ 1 ]} ist ein weit verbreitetes Versionsschema ^{[ 7 ]} , das eine Version durch eine dreiteilige Versionsnummer (Hauptversion.Nebenversion.Patch), ein optionales Vorabversions-Tag und ein optionales Build-Meta-Tag kodiert. In diesem Schema werden Risiko und Funktionalität als Kriterien für die Bedeutung von Änderungen herangezogen. Inkompatible Änderungen werden durch eine Erhöhung der Hauptversionsnummer (hohes Risiko) gekennzeichnet; neue, nicht inkompatible Funktionen erhöhen die Nebenversionsnummer (mittleres Risiko); und alle anderen nicht inkompatiblen Änderungen erhöhen die Patchnummer (geringstes Risiko). Das Vorhandensein eines Vorabversions-Tags (-alpha, -beta) deutet auf ein erhebliches Risiko hin, ebenso wie eine Hauptversionsnummer von Null (0.yz), die für eine laufende Entwicklung steht, die potenziell inkompatible Änderungen jeglicher Art enthalten kann (höchstes Risiko). Ein Beispiel für die Ableitung von Kompatibilität aus einer SemVer-Version: Software, die auf Version 2.1.5 einer API basiert, ist mit Version 2.2.3 kompatibel, aber nicht unbedingt mit 3.2.4.

Eine vierte Zahl kann auch zur Kennzeichnung der Softwareversion verwendet werden , wie es beispielsweise bei Adobe Flash der Fall war . Einige Unternehmen fügen außerdem das Build-Datum sowie Buchstaben und andere Zeichen hinzu, wie etwa Lotus 1-2-3 Release 1a.

Entwickler können mehrere Nebenversionen gleichzeitig überspringen, um anzuzeigen, dass wichtige Funktionen hinzugefügt wurden, die jedoch nicht ausreichen, um eine Erhöhung der Hauptversionsnummer zu rechtfertigen; beispielsweise Internet Explorer 5 von 5.1 auf 5.5 oder Adobe Photoshop 5 auf 5.5. Dies kann geschehen, um den Wert des Upgrades für den Softwarenutzer hervorzuheben oder, wie im Fall von Adobe, um eine Version zwischen zwei Hauptversionen darzustellen (wobei die sequenzbasierte Versionsnummerierung nicht unbedingt auf eine einzelne Ziffer beschränkt ist, wie beispielsweise bei Blender Version 2.91 oder Minecraft Java Edition von 1.7.10 bis 1.21.11, danach wurde die Versionsnummerierung auf ein jahresbasiertes Format umgestellt). ^{[ 8 ]}

Ein anderer Ansatz besteht darin, die Haupt- und Nebenversionsnummern zusammen mit einer alphanumerischen Zeichenfolge zu verwenden, die den Release-Typ angibt, z. B. „Alpha“ (a), „Beta“ (b) oder „Release Candidate“ (rc). Ein Software-Release-Train könnte nach diesem Ansatz wie folgt aussehen: 0.5, 0.6, 0.7, 0.8, 0.9 → 1.0b1, 1.0b2 (mit einigen Fehlerbehebungen), 1.0b3 (mit weiteren Fehlerbehebungen) → 1.0rc1 (falls ausreichend stabil ), 1.0rc2 (falls weitere Fehler gefunden werden) → 1.0. Es ist üblich, in diesem Schema neue Funktionen und grundlegende Änderungen während der Release-Candidate-Phasen zu sperren. Manche Teams beschränken sogar Betaversionen auf Fehlerbehebungen, um die Konvergenz zur Zielversion sicherzustellen.

Andere Schemata verleihen einzelnen Sequenzen Bedeutung:

Hauptversion.Nebenversion[.Build[.Revision]] (Beispiel: 1.2.12.102 )

Hauptversion.Nebenversion[.Wartungsversion[.Build-Version]] (Beispiel: 1.4.3.5249 )

Auch in diesen Beispielen ist die Definition dessen, was eine „größere“ im Gegensatz zu einer „kleineren“ Änderung darstellt, völlig subjektiv und liegt im Ermessen des Autors, ebenso wie die Definition eines „Builds“ oder wie sich eine „Revision“ von einer „kleineren“ Änderung unterscheidet.

Gemeinsam genutzte Bibliotheken in Linux und Solaris können das Format current.revision.age verwenden , wobei: ^{[ 9 ] [ 10 ]}

Aktuell : Die neueste Schnittstellennummer, die die Bibliothek implementiert.

Revision : Die Implementierungsnummer der aktuellen Schnittstelle.

Alter : Die Differenz zwischen der neuesten und der ältesten Schnittstelle, die die Bibliothek implementiert. Diese Verwendung des dritten Feldes ist spezifisch für libtool ; andere Bibliotheken verwenden möglicherweise eine andere Bedeutung oder ignorieren es einfach.

Ein ähnliches Problem der relativen Bedeutung von Änderungen und der Versionsnomenklatur existiert im Buchverlagswesen, wo Editionsnummern oder -namen nach unterschiedlichen Kriterien gewählt werden können.

Bei den meisten proprietären Softwareprodukten trägt die erste veröffentlichte Version die Versionsnummer 1.

Einige Projekte verwenden die Hauptversionsnummer, um inkompatible Versionen zu kennzeichnen. Zwei Beispiele hierfür sind Apache Portable Runtime (APR) ^{[ 11 ]} und das FarCry CMS ^{[ 12 ] .}

Programmierer entwickeln neue Software häufig so, dass sie abwärtskompatibel ist . Beispielsweise ist IBM z/OS so konzipiert, dass es mit drei aufeinanderfolgenden Hauptversionen des Betriebssystems im selben Sysplex einwandfrei funktioniert. Dies ermöglicht es Betreibern eines hochverfügbaren Computerclusters, die meisten Rechner betriebsbereit zu halten, während jeweils ein Rechner heruntergefahren, aktualisiert und wieder in Betrieb genommen wird. ^{[ 13 ]}

Paket-Header und Dateiformate enthalten oft eine Versionsnummer – manchmal dieselbe wie die Versionsnummer der zugehörigen Software, manchmal eine „Protokollversionsnummer“, die unabhängig von der Softwareversionsnummer ist. Der Code zur Verarbeitung alter, veralteter Protokolle und Dateiformate wird oft als Ballast betrachtet .

Software im experimentellen Stadium ( Alpha oder Beta ) verwendet häufig eine Null an der ersten („Haupt-“) Position der Sequenz, um ihren Status zu kennzeichnen. Dieses Schema ist jedoch nur für die frühen Phasen sinnvoll, nicht für zukünftige Versionen etablierter Software, deren Versionsnummer bereits über 0 hinausgeht. ^{[ 1 ]}

Zur Kennzeichnung des Status einer neueren Version werden verschiedene Schemata verwendet:

• Ein alphanumerisches Suffix ist ein gängiges Schema der semantischen Versionierung. ^{[ 1 ]} Bei diesem Schema wird den Versionen ein Bindestrich gefolgt von alphanumerischen Zeichen angehängt, um den Status anzugeben.
• Der numerische Status ist ein Schema, das Zahlen verwendet, um den Status so anzuzeigen, als wäre er Teil der Sequenz. Eine typische Wahl ist die dritte Position bei der vierstelligen Versionsnummerierung.
• Numeric 90+ ist ein weiteres Schema, das Zahlen verwendet, allerdings offenbar unter einer älteren Version. An der letzten Stelle wird eine große Zahl, typischerweise 90 oder höher, verwendet. Dieses Schema wird häufig von älteren Open-Source-Projekten wie Fontconfig genutzt .

Die beiden rein numerischen Formen verzichten auf die spezielle Logik, die für den Vergleich von "alpha < beta < rc < kein Präfix" erforderlich ist, wie sie bei der semantischen Versionierung vorkommt, allerdings auf Kosten der Verständlichkeit.

Die meisten freien und Open-Source-Softwarepakete , darunter MediaWiki , verwenden Versionsnummern als fortlaufende Zahlenfolge, getrennt durch Punkte, beispielsweise 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2 usw. Andere Softwarepakete hingegen verwenden Dezimalzahlen: 1.7, 1.8, 1.81, 1.82, 1.9 usw. Dezimalversionen waren in den 1980er-Jahren üblich, beispielsweise bei NetWare , DOS und Microsoft Windows , wurden aber auch in den 2000er-Jahren noch verwendet, etwa von Opera ^{[ 14 ]} und Movable Type . ^{[ 15 ]} Im Dezimalsystem ist 1.81 die Nebenversion nach 1.8, während Wartungsversionen (d. h. reine Fehlerbehebungen) mit einem alphabetischen Suffix gekennzeichnet werden können, z. B. 1.81a oder 1.81b.

Das Standard- Versionsnummerierungsschema von GNU lautet Hauptversion.Nebenversion.Revision ^{[ 16 ]} . Emacs ist ein bemerkenswertes Beispiel für ein anderes Schema, bei dem die Hauptversionsnummer (1) weggelassen und eine benutzerdefinierte Revisionsnummer hinzugefügt wurde, die in den Original-Emacs-Paketen immer null ist, aber von den Distributoren erhöht wird ^{[ 17 ]} . Ähnlich werden Debian -Paketnummern mit einem optionalen Präfix „Epoche“ versehen, das die Änderung des Versionsschemas ermöglicht ^{[ 18 ] .}

In einigen Fällen entscheiden sich Entwickler dafür, die Hauptversionsnummer zurückzusetzen. Dies wird mitunter verwendet, um den Beginn einer neuen Entwicklungsphase zu kennzeichnen. Beispielsweise lief die Minecraft- Alpha-Phase von Version 1.0.0 bis 1.2.6. Mit der Veröffentlichung der Beta-Phase wurde die Hauptversionsnummer zurückgesetzt und die Versionsnummern reichten von 1.0 bis 1.8. Nach der vollständigen Veröffentlichung des Spiels wurde die Hauptversionsnummer wieder auf 1.0.0 zurückgesetzt. ^{[ 19 ]}

Manche Projekte verwenden negative Versionsnummern. Ein Beispiel ist der SmartEiffel -Compiler, der bei −1.0 begann und bis 0.0 hochzählte. ^{[ 17 ]}

Um die Sortierung zu vereinfachen, verwenden manche Softwarepakete für jede Komponente des Schemas Hauptversion.Nebenversion.Release eine feste Breite. Perl stellt seine Versionsnummern als Gleitkommazahl dar; beispielsweise kann die Perl-Version 5.8.7 auch als 5.008007 dargestellt werden. Dadurch lässt sich eine theoretische Version 5.8.10 als 5.008010 darstellen. Andere Softwarepakete packen jedes Segment in eine feste Bitbreite; beispielsweise würde unter Microsoft Windows die Versionsnummer 6.3.9600.16384 als Hexadezimalwert 0x0006000325804000 dargestellt. Das Gleitkommaschema funktioniert nicht mehr, wenn ein Segment der Versionsnummer 999 überschreitet; ein gepacktes Binärschema mit jeweils 16 Bit pro Segment funktioniert nicht mehr ab 65535.

Zwischen den Versionen 1.0 und 2.6.x verwendete der Linux-Kernel ungerade Nebenversionsnummern für Entwicklungsversionen und gerade Nebenversionsnummern für stabile Versionen. Beispielsweise war Linux 2.3 eine Entwicklungsfamilie des zweiten Hauptdesigns des Linux-Kernels, und Linux 2.4 war die stabile Versionsfamilie, die aus Linux 2.3 hervorging. Nach der Nebenversionsnummer folgte die Versionsnummer in aufsteigender Reihenfolge; beispielsweise Linux 2.4.0 → Linux 2.4.22. Seit der Veröffentlichung des Kernels 2.6 im Jahr 2004 verwendet Linux dieses System nicht mehr und hat einen deutlich kürzeren Release-Zyklus.

Das gleiche System mit geraden und ungeraden Zahlen wird auch von anderer Software mit langen Releasezyklen verwendet, beispielsweise von Node.js bis Version 0.12 sowie von WineHQ . ^{[ 20 ]}

Viele Projekte verwenden ein datumsbasiertes Versionierungsschema namens Calendar Versioning (auch CalVer ^{[ 21 ]} genannt ).

Ubuntu ist ein Beispiel für ein Projekt, das Kalenderversionierung verwendet; Ubuntu 18.04 wurde beispielsweise im April 2018 veröffentlicht. Dies hat den Vorteil, dass es sich leicht mit Entwicklungs- und Supportzeitplänen verknüpfen lässt. Auch einige Videospiele nutzen das Datum als Versionsnummer, beispielsweise das Arcade-Spiel Street Fighter EX . Beim Start wird die Versionsnummer als Datum plus Regionscode angezeigt, beispielsweise 961219 ASIA .

Bei der Verwendung von Datumsangaben in der Versionsverwaltung, beispielsweise in Dateinamen, ist das ISO-8601- Schema ^{[ 22 ]} JJJJ-MM-TT üblich , da es sich leicht aufsteigend oder absteigend sortieren lässt. Die Bindestriche werden manchmal weggelassen. Das Wine- Projekt verwendete früher ein datumsbasiertes Versionsschema mit Jahr, Monat und Tag der Veröffentlichung, beispielsweise „Wine 20040505“. Die ersten Entwicklungsversionen von Minecraft hatten ein ähnliches Versionsformat, verwendeten aber das Format TT-TT-MM, beispielsweise wurde rd-131655 am 13. Mai 2009 um 16:21 Uhr erstellt.

Die Buildnummern von Microsoft Office sind ein kodiertes Datum: ^{[ 23 ]} Die ersten beiden Ziffern geben die Anzahl der Monate an, die seit Januar des Projektstartjahres vergangen sind (wobei jede Hauptversion von Office ein separates Projekt darstellt), während die letzten beiden Ziffern den Tag des jeweiligen Monats angeben. So ist 3419 der 19. Tag des 34. Monats nach Januar des Projektstartjahres.

Weitere Beispiele, bei denen Versionen anhand des Erscheinungsjahres gekennzeichnet werden, sind Adobe Illustrator 88 und WordPerfect Office 2003. Die Verwendung eines Erscheinungsjahres zur Versionsangabe dient in der Regel Marketingzwecken; zusätzlich existiert eine tatsächliche Versionsnummer. So wird beispielsweise Windows 95 intern als MS-DOS 7.00 und Windows 4.00 versioniert; Windows 2000 hingegen als NT 5.0. ^{[ 24 ]}

Manche Softwarehersteller verwenden unterschiedliche Schemata zur Kennzeichnung ihrer Softwareversionen. Das Debian-Projekt verwendet für die Versionen seines Betriebssystems ein Haupt-/Nebenversionsschema, nutzt aber während der Entwicklung Codenamen aus dem Film Toy Story, um stabile, instabile und Testversionen zu bezeichnen. ^{[ 25 ]}

BLAG Linux und GNU verwenden sehr große Versionsnummern: Hauptversionen haben Nummern wie 50000 und 60000, während Nebenversionen die Nummer jeweils um 1 erhöhen (z. B. 50001, 50002). Alpha- und Betaversionen erhalten Dezimalversionsnummern, die etwas kleiner als die Hauptversionsnummer sind, z. B. 19999.00071 für Alpha 1 der Version 20000 und 29999.50000 für Beta 2 der Version 30000. ^{[ 26 ] [ 27 ] [ 28 ]}

Urbit verwendet die Kelvin-Versionierung (benannt nach der absoluten Kelvin- Temperaturskala): Softwareversionen beginnen mit einer hohen Zahl und zählen bis Version 0 herunter, ab der die Software als fertiggestellt gilt und keine weiteren Änderungen mehr vorgenommen werden. ^{[ 29 ] [ 30 ]}

In Verbindung mit den verschiedenen oben aufgeführten Versionsschemata wird im Allgemeinen ein System zur Kennzeichnung von Vorabversionen verwendet, während das Programm die verschiedenen Phasen des Software-Release-Lebenszyklus durchläuft .

Programme in einem frühen Entwicklungsstadium werden oft als „Alpha“-Software bezeichnet, nach dem ersten Buchstaben des griechischen Alphabets. Sobald sie ausgereifter sind, aber noch nicht zur Veröffentlichung bereit, werden sie als „Beta“-Software bezeichnet, nach dem zweiten Buchstaben des griechischen Alphabets. Alpha-Software wird in der Regel nur von den Entwicklern getestet, während Beta-Software zur Erprobung durch die Community bereitgestellt wird.

Manche Systeme verwenden Versionsnummern kleiner als 1 (z. B. 0.9), um ihren Weg zur finalen Version „1.0“ zu kennzeichnen. Dies ist eine gängige Konvention in Open-Source-Software . ^{[ 31 ] [ 32 ]} Handelt es sich bei der Vorabversion jedoch um eine bestehende Software (z. B. Version 2.5), kann der Versionsnummer ein „a“ oder „alpha“ angehängt werden. So könnte die Alpha-Version von Version 2.5 beispielsweise als 2.5a oder 2.5.a. bezeichnet werden.

Eine Alternative besteht darin, Vorabversionen als „Release Candidates“ zu bezeichnen, sodass Softwarepakete, die demnächst als eine bestimmte Version veröffentlicht werden, diese Versionskennzeichnung gefolgt von „rc-#“ tragen, was die Nummer des Release Candidates angibt; wenn die endgültige Version veröffentlicht wird, wird die Kennzeichnung „rc“ entfernt.

Versionsnummern dienen dem Verbraucher ( Kunde) dazu, seine Softwarekopie mit einer anderen zu vergleichen, beispielsweise mit der neuesten Version des Entwicklers. Programmierer und Unternehmen nutzen Versionsnummern häufig revisionsbasiert, um einzelne Softwarekomponenten mit neueren oder älteren Revisionen derselben Komponenten zu vergleichen, oft in einem kollaborativen Versionskontrollsystem .

Im 21. Jahrhundert begannen immer mehr Programmierer, formalisierte Versionsrichtlinien wie die semantische Versionierung zu verwenden. ^{[ 1 ]} Solche Richtlinien sollen es anderen Programmierern erleichtern, zu erkennen, wann Codeänderungen wahrscheinlich ihre eigenen Anwendungen beeinträchtigen. Sie sind besonders wichtig für Softwarebibliotheken und Frameworks , können aber auch für Kommandozeilenanwendungen (die von anderen Anwendungen aufgerufen werden können) und andere Anwendungen (die von Dritten per Skript erstellt und/oder erweitert werden können) sehr nützlich sein.

Ein Software-Release-Train ist eine Form des Software-Release-Plans, bei dem mehrere separate Serien versionierter Software-Releases für verschiedene Produkte regelmäßig als verschiedene „Trains“ veröffentlicht werden. In der Regel laufen für jede Produktlinie mehrere Release-Trains gleichzeitig, wobei jeder Train planmäßig von der ersten Veröffentlichung bis zur endgültigen Reife und Stilllegung durchläuft. Benutzer können mit einem neueren Release-Train experimentieren, bevor sie ihn produktiv einsetzen. So können sie frühzeitig mit neueren, noch unfertigen Versionen testen und gleichzeitig die Punkt-Releases des vorherigen Trains für ihre Produktionssysteme weiterverfolgen, bevor sie auf den neuen, ausgereiften Release-Train umsteigen.

Ciscos IOS- Softwareplattform nutzte viele Jahre lang ein Release-Train-Modell mit zahlreichen separaten Release-Zügen. In jüngerer Zeit haben auch eine Reihe anderer Plattformen, darunter Firefox und Fenix ​​für Android ^{[ 33 ]} , Eclipse ^{[ 34 ]} , LibreOffice ^{[ 35 ]} , Ubuntu ^{[ 36 ]} , Fedora ^{[ 37 ]} , Python ^{[ 38 ]} , digiKam ^{[ 39 ]} und VMware ^{[ 40 ]} , dieses Release-Train-Modell übernommen.

Software kann eine interne Versionsnummer haben, die von der im Produktnamen angegebenen Versionsnummer abweicht (und in der Regel den Versionsnummerierungsregeln konsequenter folgt). Java SE 5.0 hat beispielsweise die interne Versionsnummer 1.5.0, und Windows-Versionen ab NT 4 verwenden intern weiterhin die Standardversionsnummern: Windows 2000 ist NT 5.0, XP ist Windows NT 5.1, Windows Server 2003 und Windows XP Professional x64 Edition sind NT 5.2, Windows Server 2008 und Vista sind NT 6.0, Windows Server 2008 R2 und Windows 7 sind NT 6.1, Windows Server 2012 und Windows 8 sind NT 6.2 und Windows Server 2012 R2 und Windows 8.1 sind NT 6.3. Windows 10 sollte ursprünglich NT 6.4 sein, da die früheste öffentlich zugängliche Technical Preview-Version die Nummer 6.4.9841 trägt. Dies hielt jedoch nicht lange an, da die Versionsnummer von Windows 10 schnell künstlich auf 10.0 erhöht wurde ^{[ 41 ]} , um sie an den kommerziellen Namen anzupassen. Die erste veröffentlichte Version des Betriebssystems trug daher die Nummer 10.0.10240. Windows NT befindet sich allerdings erst in der fünften Hauptversion, da die erste Version die Nummer 3.1 trug (passend zur damals üblichen Windows-Versionsnummer) und Windows 10 mit einem Versionssprung von 6.3 auf 10.0 aufwartete.

Eine relativ gängige Praxis ist es, aus Marketinggründen große Versionsnummernsprünge vorzunehmen. Manchmal überspringen Softwareanbieter die Version 1.0 einfach oder veröffentlichen schnell eine Version mit einer höheren Versionsnummer, da Software der Version 1.0 von vielen Kunden als zu unausgereift für den Produktiveinsatz angesehen wird. Beispielsweise wird bei dBase II ein Produkt mit einer Versionsnummer eingeführt, die einen höheren Reifegrad suggeriert, als tatsächlich vorhanden ist.

Manchmal werden Versionsnummern auch erhöht, um mit denen der Konkurrenz mitzuhalten. Dies lässt sich an vielen Beispielen der Produktversionsnummerierung von Microsoft, America Online , Sun Solaris , Java Virtual Machine , SCO Unix und WordPerfect beobachten . Microsoft Access sprang von Version 2.0 auf Version 7.0, um mit der Versionsnummer von Microsoft Word übereinzustimmen .

Auch Microsoft war Ziel von „Aufhol“-Versionsänderungen. So übersprangen die Netscape -Browser die Versionsnummern 5 und 6, analog zum Internet Explorer von Microsoft . Dies lag aber auch daran, dass die Mozilla-Anwendungssuite während der Entwicklung vor Version 1.0 die Versionsnummer 5 in ihrem User-Agent -String übernommen hatte und Netscape 6.x auf der Mozilla-Codebasis aufbaute. Ein weiteres Beispiel für das Aufholen gegenüber Wettbewerbern ist der Versionssprung von Slackware Linux von Version 4 auf Version 7 im Jahr 1999. ^{[ 42 ]}

Dieser Ansatz, der von vielen kritisiert wird, weil er die semantische Bedeutung der Abschnitte der Versionsnummer beeinträchtigt, wird von einer zunehmenden Anzahl von Anbietern, darunter Mozilla (für Firefox ) und Google (für Google Chrome ), übernommen. ^{[ 43 ]}

Suns Java hatte zeitweise ein Hybridsystem, bei dem die interne Versionsnummer immer 1.x lautete, aber nur unter Bezugnahme auf x vermarktet wurde :

• JDK 1.0.3
• JDK 1.1.2 bis 1.1.8
• J2SE 1.2.0 („Java 2“) bis 1.4.2
• Java 1.5.0, 1.6.0, 1.7.0, 1.8.0 („Java 5, 6, 7, 8“)

Sun ließ auch die erste Ziffer bei Solaris weg, sodass Solaris 2.8 (oder 2.9) in Marketingmaterialien als Solaris 8 (oder 9) bezeichnet wird.

Ein ähnlicher Sprung erfolgte Anfang der 2010er Jahre mit dem Open-Source-PBX-Baukasten Asterisk , dessen Projektleiter ankündigten, dass auf die aktuelle Version 1.8.x bald die Version 10 folgen würde. ^{[ 44 ]}

Die Freie-Software- und Open-Source -Communitys veröffentlichen Software tendenziell früh und häufig . Anfangsversionen haben Nummern kleiner als 1. Diese 0.x-Versionen signalisieren, dass die Software unvollständig und noch nicht zuverlässig genug für eine allgemeine Veröffentlichung oder im aktuellen Zustand nutzbar ist. Rückwärtsinkompatible Änderungen sind bei 0.x-Versionen üblich. Version 1.0 gilt als wichtiger Meilenstein und signalisiert, dass die Software mindestens alle wichtigen Funktionen sowie die von den Entwicklern gewünschten Features enthält und als zuverlässig genug für eine allgemeine Veröffentlichung gilt. ^{[ 31 ] [ 32 ]} Ein gutes Beispiel hierfür ist der Linux-Kernel, der 1991 als Version 0.01 veröffentlicht wurde ^{[ 45 ]} und erst 1994 Version 1.0.0 erreichte. ^{[ 46 ]}

Die Entwickler des Arcade- Spielemulators MAME beabsichtigen nicht, jemals eine Version 1.0 des Programms zu veröffentlichen, da es immer weitere Arcade-Spiele zu emulieren geben wird und das Projekt somit nie wirklich abgeschlossen werden kann. Dementsprechend folgte auf Version 0.99 die Version 0.100. ^{[ 47 ]}

• Die Office-2007-Version von Microsoft Office hatte die interne Versionsnummer 12. Die Nachfolgeversion, Office 2010, trägt aufgrund von Aberglauben um die Zahl 13 die interne Versionsnummer 14. ^{[ 48 ]} Visual Studio 2013 ist die Versionsnummer 12.0, und die neue Version, Visual Studio 2015, trägt aus denselben Gründen die Versionsnummer 14.0.
• Roxio Toast ging von Version 12 auf Version 14 über, wahrscheinlich um den Aberglauben rund um die Zahl 13 zu umgehen.
• Corels WordPerfect Office , Version 13 , wird als „X3“ ( römische Zahl 10 und „3“) vermarktet . Dieses Vorgehen wurde in der Nachfolgeversion X4 fortgesetzt. Dasselbe gilt für Corels Grafik-Suite (d. h. CorelDRAW , Corel Photo-Paint ) sowie die Videobearbeitungssoftware „Video Studio“.
• Sybase übersprang bei seinem relationalen Datenbankprodukt Adaptive Server Enterprise die Hauptversionen 13 und 14 und ging direkt von Version 12.5 auf 15.0 über.
• Das ABBYY Lingvo Wörterbuch verwendet die Nummerierung 12, x3 (14), x5 (15).
• SUSE Linux Enterprise übersprang nach Version 12 die Versionen 13 und 14 und veröffentlichte im Juli 2018 direkt SLES 15.
• Mitte der 1990er-Jahre wechselte das schnell wachsende CMMS-System Maximo direkt von der Maximo-Serie 3 zur Serie 5 und übersprang die Serie 4 aufgrund der vermeintlichen Vermarktungsschwierigkeiten auf dem chinesischen Markt, wo die Zahl 4 mit „Tod“ assoziiert wird (siehe Tetraphobie ). Dies hinderte die Veröffentlichung von Maximo Serie 5 Version 4.0 jedoch nicht. (Die Bezeichnung „Serie“ wurde inzwischen abgeschafft, wodurch die Versionsnummern nach der Veröffentlichung von Serie 5 Version 1.0 effektiv zurückgesetzt wurden.)

• Die SUSE Linux- Distribution begann mit Version 4.2, in Anlehnung an 42 , „die Antwort auf die ultimative Frage nach dem Leben, dem Universum und dem ganzen Rest“, die in Douglas Adams ' Per Anhalter durch die Galaxis erwähnt wird .
• Eine Slackware Linux-Distribution wurde mit der Versionsnummer 13.37 versehen, wobei auf leet verwiesen wurde .
• Finnix übersprang die Versionsnummer 93.0 und ging direkt zu 100 über, unter anderem um der Aussage „There Will Be No Finnix '95“ gerecht zu werden, eine Anspielung auf Windows 95. ^{[ 49 ]}
• Die Spezifikation des Tagged Image File Format verwendet seit ihrer Einführung die interne Versionsnummer 42. Ihre Entwickler gehen nicht davon aus, diese während ihrer (oder ihrer) Lebensdauer noch einmal zu ändern, da dies mit ihren Entwicklungsrichtlinien in Konflikt geraten würde.

Die Python Software Foundation hat PEP 440 – Version Identification and Dependency Specification ^{[ 50 ]} veröffentlicht, in dem sie ihr eigenes flexibles Schema darlegt, das ein Epochensegment, ein Release-Segment, Vorab- und Nachab-Segmente sowie ein Entwicklungs-Release-Segment definiert.

TeX verwendet ein eigenwilliges Versionsnummerierungssystem, eine ungewöhnliche Eigenart, die von seinem Entwickler Donald Knuth erfunden wurde . Seit Version 3.1 werden Aktualisierungen durch das Hinzufügen einer zusätzlichen Ziffer am Ende der Versionsnummer gekennzeichnet, sodass diese asymptotisch gegen π strebt . Somit entspricht 3.14 in der semantischen Versionierung effektiv 3.2. (Dies ist eine Form der unären Nummerierung ; die Versionsnummer entspricht der Anzahl der Ziffern.) Seit 2021 lautet die Versionsnummer 3.141592653. Dies spiegelt die hohe Stabilität von TeX wider, und es sind nur kleinere Aktualisierungen zu erwarten. TeX-Entwickler Donald Knuth hat erklärt, dass die „absolut letzte Änderung (nach [seinem] Tod)“ darin bestehen wird, die Versionsnummer auf π zu ändern . Ab diesem Zeitpunkt werden alle verbleibenden Fehler zu permanenten Funktionen. ^{[ 51 ]}

In ähnlicher Weise nähert sich die Versionsnummer von Metafont asymptotisch der Eulerschen Zahl e an . ^{[ 51 ]} Im Februar 2021 lautete die Versionsnummer 2,71828182. Metafont wurde von Donald Knuth als Ergänzung zu seinem TeX-Satzsystem entwickelt.

In der Ära des klassischen Mac OS gingen die Versionsnummern selten über „.1“ hinaus. Wenn doch, sprangen sie meist direkt auf „.5“, um zu suggerieren, dass die Veröffentlichung „bedeutender“ sei. ^{[ a ]} So wurde „8.5“ als eigenständige Version vermarktet und stand für „Mac OS 8½“, während 8.6 im Grunde „8.5.1“ bedeutete.

Mac OS X wich von diesem Trend ab, vor allem weil das „X“ (die römische Zahl für 10) im Produktnamen enthalten war. Daher begannen alle OS-X-Versionen mit der Zahl 10. Die erste Hauptversion von OS X erhielt die Versionsnummer 10.0, die nächste jedoch nicht 11.0, sondern 10.1, gefolgt von 10.2, 10.3 usw. für jede weitere Hauptversion. Die elfte Hauptversion von OS X trug somit die Bezeichnung „10.10“. Obwohl das „X“ ab macOS 10.12 aus dem Namen entfernt wurde , blieb dieses Nummerierungsschema bis macOS 10.15 erhalten. Bei diesem „X“-basierten Versionierungsschema kennzeichnete die dritte Ziffer (anstatt der zweiten) eine Nebenversion. Zusätzliche Aktualisierungen unterhalb dieser Ebene sowie Aktualisierungen einer bestimmten Hauptversion von OS X, die nach der Veröffentlichung einer neuen Hauptversion erschienen, wurden als „Supplemental Updates“ bezeichnet. ^{[ 52 ]}

Die römische Ziffer X wurde gleichzeitig für Marketingzwecke in verschiedenen Produktlinien eingesetzt. Sowohl QuickTime als auch Final Cut Pro sprangen direkt von Version 7 auf Version 10, QuickTime X bzw. Final Cut Pro X. Wie Mac OS X selbst handelte es sich bei den Produkten nicht um Upgrades vorheriger Versionen, sondern um komplett neue Programme. Wie bei OS X wurde bei größeren Versionen die zweite Ziffer erhöht, bei kleineren Versionen die dritte. Mit der Veröffentlichung von macOS 11.0 (siehe unten) verschwand das „X“ aus dem Namen Final Cut, und die Marke QuickTime verlor an Bedeutung, als das Framework 2011 zugunsten von AVFoundation eingestellt wurde (das Programm zum Abspielen von QuickTime-Videos hieß von Anfang an nur QuickTime Player).

Die nächste macOS-Version von Apple, vorläufig mit der Nummer 10.16 ^{[ 53 ]} , wurde im Juni 2020 auf der WWDC offiziell als macOS 11 angekündigt und im November 2020 veröffentlicht. ^{[ 54 ]} Die darauffolgende macOS-Version, macOS Monterey , wurde im Oktober 2021 veröffentlicht und erhöhte ihre Hauptversionsnummer auf 12. ^{[ 55 ]}

Im Juni 2025 kündigte Apple ein einheitliches Versionsschema an, bei dem die Jahreszahl neben dem Veröffentlichungsdatum angegeben wird, ähnlich wie bei Fahrzeugen . Die im Herbst 2025 veröffentlichten Versionen sind iOS 26, macOS 26, iPadOS 26, tvOS 26, watchOS 26 und visionOS 26. ^{[ 56 ]}

Das Microsoft Windows -Betriebssystem wurde zunächst mit Standardversionsnummern von Windows 1.01 bis Windows 3.2 gekennzeichnet . Danach ließ Microsoft die Versionsnummer aus dem Produktnamen weg. Bei Windows 95 (Version 4.0), Windows 98 (4.10) und Windows 2000 (5.0) wurde das Erscheinungsjahr im Produktnamen angegeben. Nach Windows 2000 entwickelte Microsoft die Windows Server- Familie, die den jahresbasierten Stil mit einer Änderung beibehielt: Für kleinere Versionen fügte Microsoft dem Titel „R2“ hinzu, z. B. Windows Server 2008 R2 (Version 6.1). Dieser Stil blieb bis heute unverändert. Die Clientversionen von Windows hingegen verwendeten keinen einheitlichen Stil. Zuerst erhielten sie Namen mit willkürlichen alphanumerischen Suffixen, wie beispielsweise Windows Me (4.90), Windows XP (5.1) und Windows Vista (6.0). Später führte Microsoft erneut fortlaufende Nummern im Titel ein, diesmal jedoch keine Versionsnummern. Die Versionsnummern von Windows 7 , Windows 8 und Windows 8.1 lauten 6.1, 6.2 bzw. 6.3. Bei Windows 10 sprang die Versionsnummer auf 10.0 ^{[ 57 ]} , und nachfolgende Updates des Betriebssystems erhöhten lediglich die Buildnummer (die datumsbasiert ist) und die Update-Build-Revisionsnummer (UBR).

Der Nachfolger von Windows 10, Windows 11 , wurde am 5. Oktober 2021 veröffentlicht. Obwohl er den Namen „11“ trägt, wurde die Hauptversionsnummer der neuen Windows-Version nicht auf 11 angehoben. Stattdessen blieb sie bei der gleichen Versionsnummer 10.0, die auch von Windows 10 verwendet wurde. ^{[ 58 ]}

Manche Dateisysteme , wie beispielsweise das OpenVMS-Dateisystem , verwalten ebenfalls Dateiversionen. Die Versionsverwaltung von Dokumenten ähnelt der Vorgehensweise in der Computer- und Softwareentwicklung: Bei jeder kleinen Änderung an Struktur, Inhalt oder Bedingungen wird die Versionsnummer um 1 oder einen kleineren bzw. größeren Wert erhöht, je nach Präferenz des Autors und Umfang bzw. Wichtigkeit der Änderungen.

Technische Zeichnungen und CAD-Softwaredateien verwenden möglicherweise auch eine Art primitive Versionsnummer, um Änderungen nachzuverfolgen.

• Veröffentlichungsplan der Document Foundation für LibreOffice, der die Release-Züge zeigt