Vergabe von Versionsnummern

Version

Eine Versionsnummer ist eine Kennzeichnung verschiedener Arbeitsfortschritte. So ist es möglich auch ältere Arbeitsschritte zu erkennen, wiederherzustellen und Änderungen zu verfolgen. In Abb. 1a sehen sie, das die Version von Microsoft® Windows® 2000 mit Service Pack 4, die im Bild mit einem • markiert ist, 5.00.2195 lautet. Die Vergabe besteht hier aus folgenden Teilen:

Hauptversionsnummer (englisch Major Release)

Sie gibt an, die wievielte Datenstruktur oder Programm-Neuauflage vorliegt. Es ist das 5. Windows® Betriebssystem, laut der Version, in Abb. 1a.

Nebenversionsnummer (englisch Minor Release)

Die wievielte Verbesserung der Funktionalität wurde bei diesem Programm, mit der Hauptversionsnummer vorgenommen. Die Version in Abb. 1a gibt an, das keine weitere Funktionalität hinzugefügt wurde. Das heißt, alles war schon im Service Pack 4 enthalten.

Buildnummer (englisch Build number)

Anzahl der Übersetzungen von der Programmsprache in die Maschinensprache. Diese Windows® 2000 Version wurde 2.195 mal übersetzt.

Revisionsnummer (englisch Patch level)

Gibt an, wie viele Fehler behoben worden. In der Abb. 1a wird das nicht angegeben.

Semantische Versionierung

Die semantische Versionierung ist ein recht neues Versionierungsschema und findet gern Verwendung in Programmbibliotheken (z.B. auf Linux). Das primäre Ziel der semantischen Versionierung ist das Minimieren der sogenannten Dependency Hell mit einem einfachen Regelwerk. Das bedeutet, die Versionsnummer selbst gibt Auskunft darüber, ob die Programmbibliothek immer noch kompatibel zum Programm ist oder nicht.

Die semantische Versionsnummer MAJOR.MINOR.PATCH bzw. a.b.c ist immer dreiteilig aufgebaut und hat zusammengefasst folgende Regeln:

1. MAJOR (a) = wird erhöht, wenn die Schnittstelle bzw. Datenstruktur selbst Änderungen hat, die mit der Vorgängerversion nicht (mehr) kompatibel sind.
2. MINOR (b) = wird erhöht, wenn neue Funktionen oder Verbesserungen dazu kommen, ohne das sich die Schnittstelle selbst ändert, also immer noch kompatibel zur Vorgängerversion bleibt.
3. PATCH (c) = wird erhöht, wenn kleine Änderungen und Fehlerkorrekturen gemacht werden, ohne das sich die Schnittstelle selbst ändert, also immer noch kompatibel zur Vorgängerversion bleibt.

Jede Nummer bei dieser Versionierung zählt unendlich lange hoch, das heißt, wenn man z.B. bei v1.1.9 ist und eine weitere Fehlerkorrektur dazu kommt, dann wäre die nächste Versionsnummer v1.1.10. Wird in einer vorangegangenen Stelle, (a) oder (b), die Nummer erhöht, werden, wie in der Vergabe von Versionsnummern üblich, alle nachfolgenden Stellen genullt!

Im Prinzip merkt man sich hier nur folgendes: Solange, wie sich die MAJOR-Nummer nicht ändert, sollte die Programmbibliothek im verwendeten Programm kompatibel bleiben.

Beim Beginn der Entwicklung fängt die Version in der Regel bei v0.1.0 an und bei der Erstauslieferung sollte sie möglichst v1.0.0 sein.

Eine sehr ausführliche Beschreibung des Regelwerks, der Hintergrund und die Edge Cases mit verschiedenen Übersetzungen finden Sie hier: https://semver.org/

Beispiel

Hier nun ein Beispiel, wie man damit arbeitet:

1. Ein neues Projekt wurde in Auftrag gegeben und ein Prototyp mit der Version v0.1.0 wurde entwickelt und vorgestellt.
2. Der Auftraggeber ist an sich zufrieden, wünscht jedoch einige Änderungen an der Funktionalität. Insgesamt hat das Projekt nun insgesamt 23 neue bzw. verbesserte Funktionen, also stieg die Version auf v0.24.0 an.
3. Der Auftraggeber ist nun vollständig zufrieden und wünscht aufgrund der bald erreichten Deadline das Release. Die Version ändert sich nun auf v1.0.0.
4. Nach dem Release haben verschiedene Nutzer dieses Projekts insgesamt 56 Fehler gefunden. Die Softwareentwicklung hat die Fehler behoben und die Version lautet nun v1.0.56.
5. Viele Nutzer fragten häufig, ob es möglich wäre, 2 bestimmte Funktionen hinzuzufügen. Dem wurde zugestimmt und die Umsetzung führte zur Version v1.1.0.
6. In der Softwareentwicklung hat sich durch Experimente herausgestellt, dass die Nutzerdaten im Projekt viel effizienter gespeichert werden können, jedoch macht diese Änderung das Projekt inkompatibel zu den Vorgängerversionen. Das Projekt mit diesen Änderungen hat nun die Version v2.0.0.
7. …

Erweiterte Versionierung

Die Versionsnummer der erweiterten Versionierung ermöglicht das genauere Ablesen des Arbeitszustands, da auch die Anzahl der Kompilierungen angegeben wird. Zusätzlich hat diese Versionierung nicht das Problem, wie bei der klassischen Versionierung, dass MINOR und PATCH miteinander addiert werden. Ein großer Nachteil ist, dass durch die längere, detailliertere Versionsnummer, die Version schlechter, vor allem für den Anwender, abzulesen ist. Beispiel: v17.7652.344.191466. Diese Art der Versionierung wird z.B. bei der Entwicklung für Desktop-Programme auf Windows® mehr oder weniger vorgegeben, das heißt, eine Windows-Executable hat immer das Versionsnummernformat a.b.c.d.

Die erweiterte Versionsnummer MAJOR.MINOR.PATCH.BUILD bzw. a.b.c.d ist immer vierteilig aufgebaut und hat zusammengefasst folgende Regeln:

1. MAJOR (a) = zeigt die Anzahl der Änderungen der Datenstruktur an.
2. MINOR (b) = zeigt die Anzahl der Verbesserungen in der Funktionalität an.
3. PATCH (c) = zeigt die Anzahl der Fehlerbeseitigungen.
4. BUILD (d) = zeigt die Anzahl der Übersetzungen von der Programmiersprache in die Maschinensprache.

Jede Nummer bei dieser Versionierung zählt unendlich lange hoch, das heißt, wenn man z.B. bei v1.1.9.433 ist und eine weitere Fehlerkorrektur dazu kommt, dann wäre die nächste Versionsnummer v1.1.10.434. Wird in einer vorangegangenen Stelle, (a), (b) oder (c), die Nummer erhöht, werden (bis auf die BUILD-Nummer), wie in der Vergabe von Versionsnummern üblich, alle nachfolgenden Stellen genullt!

Beim Beginn der Entwicklung fängt die Version in der Regel bei v0.1.0.0 an und bei der Erstauslieferung sollte sie möglichst v1.0.0.x sein, wobei x für die fortlaufende BUILD-Nummer steht.

Beispiel

Hier nun ein Beispiel, wie man damit arbeitet:

1. Die Softwareentwicklung ist aktuell auf dem Stand der Version v4.56.0.300.
2. Es wurden 6 Fehlerkorrekturen gemacht, welche beim Entwicklungsprozess 10 Kompilationen verursacht haben. Die Version lautet nun v4.56.6.310.
3. Es wurden weitere 5 Fehlerkorrekturen gemacht, welche beim Entwicklungsprozess 7 weitere Kompilationen verursacht haben. Die Version lautet nun v4.56.11.317
4. Eine Funktionalität wurde überarbeitet, welche beim Entwicklungsprozess 4 Kompilationen verursacht haben. Die Version lautet nun v4.57.0.321.
5. Eine neue Datenstruktur wurde hinzugefügt, welche beim Entwicklungsprozess 43 Kompilationen verursacht haben. Die Version lautet nun v5.0.0.364.
6. …

Klassische Versionierung

Die Versionsnummer der klassischen Versionierung ist leicht zu lesen, dadurch Kundenorientierter und kann damit auch Verkaufsfördernder sein. Der Anwender erkennt auch schnell wie der Entwicklungsstatus ist, allerdings kann er nicht gleich sehen, wie viele Fehler behoben worden sind, da dies mit der Funktionalitätsverbesserung vermischt sein kann.

Die klassische Versionsnummer MAJOR.MINOR+PATCH bzw. a.bcd ist immer zweiteilig aufgebaut, vergleichbar mit einer Fixed-Point-Dezimalzahl und hat zusammengefasst folgende Regeln:

1. MAJOR (a) = zeigt die Anzahl der Änderungen der Datenstruktur an.
2. MINOR (bc) = zeigt die Anzahl der Verbesserungen in der Funktionalität an.
3. PATCH (d) = zeigt die Anzahl der Fehlerbeseitigungen.

Jede Nummer bei dieser Versionierung inkrementiert die nächst höhere Nummer. Das bedeutet, wenn die Version v1.009 eine einzige, weitere Fehlerkorrektur bekommt, dann lautet die neue Version v1.010. Dies gilt selbst für die MAJOR-Nummer (a), sprich v1.999 → v2.000. Wird in einer vorangegangenen Stelle, (a) oder (bc), die Nummer erhöht, werden, wie in der Vergabe von Versionsnummern üblich, alle nachfolgenden Stellen genullt! Ansonsten gelten die Gesetze der Mathematik für die Addition, das heißt, wenn eine Stelle von 9 auf 10 erhöht wird.

Beim Beginn der Entwicklung fängt die Version in der Regel bei v0.100 an und bei der Erstauslieferung sollte sie möglichst v1.000 sein.

Beispiel

Hier nun ein Beispiel, wie man damit arbeitet:

1. Die Softwareentwicklung ist aktuell auf dem Stand der Version v4.560.
2. Es wurden 6 Fehlerkorrekturen gemacht, also gilt:
   = 4 / 1 + 56 / 100 + (0 + 6) / 1000
   = 4 + 0,56 + 0,006
   = 4,566
   → v4.566
3. Es wurden weitere 5 Fehlerkorrekturen gemacht, also gilt:
   = 4 / 1 + 56 / 100 + (6 + 5) / 1000
   = 4 + 0,56 + 0,011
   = 4,571
   → v4.571
4. Eine Funktionalität wurde überarbeitet, also gilt:
   = 4 / 1 + (57 + 1) / 100 + 0 / 1000
   = 4 + 0,58 + 0,000
   = 4,580
   → v4.580
5. Eine neue Datenstruktur wurde hinzugefügt, also gilt:
   = (4 + 1) / 1 + 0 / 100 + 0 / 1000
   = 5 + 0,00 + 0,000
   = 5,000
   → v5.000
6. …