Wie Versionsnummern das Leben erleichtern

Versionsnummern können in der Softwareentwicklung wichtig sein. Doch wann sind Versionsnummern schlecht und stören bei der Entwicklung von Software? Dieser Artikel gibt euch Tipps.

Was sind Versionsnummern

Versionsnummern geben einen bestimmten Stand einer Software, Bibliotheken oder Dokumenten an. Diese Nummern können im Prinzip überall angewendet werden und einen beliebigen Aufbau haben.

Versionsnummern definieren einen gewissen Stand. Wenn sich zwei Versionen von X unterscheiden sollte auch die Versionsnummer unterschiedlich sein.

In der Softwareentwicklung helfen die Nummern dabei festzustellen, welchen Stand ein Produkt hat. Wenn ein Benutzer eine ältere Version verwendet kann es sein, dass Probleme in einer aktuelleren Version behoben sind. Des weiteren können auch Abhängigkeiten zu anderen Softwareprodukten identifiziert und bestimmt werden. Dies ist vor allem dann wichtig, wenn diese Bibliotheken in spezifischen Versionen Fehler beinhalten oder inkompatibel mit der eigenen Software sind.

Mögliche Standards

Prinzipiell gibt es keinen festen Standard, wie Versionsnummern zu erstellen sind. Jede ( veröffentlichte) Version kann beispielsweise einfach hochgezählt werden (1, 2, 3…).

Als „Standards“ in der Softwareentwicklung haben sich SemVer (Semantic Versioning) und SimVer (Simple Versioning) herauskristallisiert.

SemVer

Semantic Versioning ist recht einfach. Es gibt 3 Stellen für eine Versionsnummer: Major.Minor.Patch. Somit haben Versionsnummern immer Formate wie 1.0.0 oder 5.4.3.

Die kurze Zusammenfassung erklärt SemVer folgendermaßen:

Die Major-Version wird hochgezählt, wenn inkompatible Änderungen zur Vorversion durchgeführt wurden. Die Minor-Version wird hochgezählt, wenn Änderungen durchgeführt wurden die Abwärtskompatibilität jedoch sichergestellt ist. Die Patch-Version sollte nur für kleinere Bugfixes verwendet werden.

Es sind beliebige Suffixe erlaubt, um Vorversionen zu definieren. Beispiele hierfür sind 1.0.0-alpha01 oder 2.3.0-beta.

SimVer

Simver sieht nur zwei Stellen in der Versionsnummer vor: Major.Minor.

In der Nutzung ist SimVer ähnlich zu SemVer. Der Einzige Unterschied besteht im Weglassen der Patch-Version. Wie bei SemVer erhöhen großen Änderungen, welche eine Abwärtskompatibilität beeinträchtigen, die Major-Version erhöht. Bei Änderungen mit Abwärtskompatibilität wird die Minor-Version erhöht.

Ungelöste Probleme

Die größte Schwierigkeit besteht vor allem darin, zu definieren oder herauszufinden, ab wann eine Änderung nicht mehr Abwärtskompatibel ist. Auch Bugs oder ungewollte Verhaltensweisen, die seit längerer Zeit im Programm oder der Bibliothek sind und behoben werden, können die Abwärtskompatibilität beeinträchtigen. Dazu reicht nur eine Gruppe Entwickler, die sich an die „andere“ Verhaltensweise gewöhnt und das Fehlverhalten nicht als solches erkennt. In meiner persönlichen Erfahrung hatte ich einmal den schlechten Fall, dass in einer genutzten Programmbibliothek plötzlich einen Memory-Leak auftauchte, obwohl ich die Bibliothek nur von 4.1 auf 4.3 aktualisiert habe.

Wie kann man als Entwickler dieses Pakets solche Fehler oder mögliche Seiteneffekte ausschließen, um eine Abwärtskompatibilität zu gewährleisten? Ist eine Abwärtskompatibilität immer notwendig?

Die beiden Vorgehensweisen geben zumindest ein einheitliches Vorgehen vor. Welchen Teil der Versionsnummer bei einer Aktualisierung erhöht wird, hängt stark von der jeweiligen Änderung und dem Projekt ab.

Disziplin und Einheitlichkeit

Als wichtigsten Punkt sehe ich Disziplin und Einheitlichkeit.

Disziplin ist vor allem dann notwendig, wenn neue Versionen veröffentlicht werden. Dieser Schritt kann durch Buildserver oder andere Prozessschritte insoweit unterstützt werden, dass Versionsnummern automatisch gesetzt oder das Veröffentlichen einer Bibliothek mit der selben Versionsnummer unterbunden wird.

Es gibt aus Sicht des Entwicklers nichts schlimmeres als zwei Bibliotheken (DLLs) mit dem identischen Namen und der identischen Version aber Programmunterschieden. Vor allem in einer Entwicklungsumgebung ist es verwirrend, wenn eine ExampleLib 2.0.0 nicht mit ExampleLib 2.0.0 übereinstimmt und inkompatibel ist.

Die Einheitlichkeit beziehe ich mich insbesondere auf Softwarepakete wie beispielsweise Nuget. Ein Nuget-Paket kann aus verschiedenen Komponenten bestehen. In der Regel ist die Version des Nuget-Paketes die gleiche Version wie die Bibliothek (DLL). Es kann allerdings vorkommen, dass die Versionen unterschiedlich sind. Es hilft dem Entwickler ungemein, wenn die Version des Paketes und die Version des Inhalts identisch sind. Wenn die Versionen einheitlich sind, treten auch solche Fehler wie der vorher genannte nicht auf. Die meisten Paketmanager erlauben kein hochladen eines Paketes unter einer schon bestehenden Versionsnummer.

Fazit

Zusammenfassend lässt sich sagen, dass Versionsnummern „sprechend“ sein sollten. Sofern es Änderungen an einer Bibliothek gibt, sollte die Version das auch wiedergeben. Pakete wie Nuget sollten eine einheitliche Versionummer für das Paket und die bereitgestellten Bibliotheken verwenden.

Was ist eure Meinung zu Versionsnummern? Habt ihr ein anderes Vorgehen?

---

Bildnachweis: Pixabay.com