Semantisches Versionieren von Software

von | Jul 21, 2018 | Programming, Tipps & Tricks

Kurzzusammenfassung

Semantisches Versionieren: Durch eine Versionsnummer wird eine Version einer Software eindeutig in einer Version identifiziert. Dabei wird die Versionsnummer der Form (HAUPT.NEBEN.PATCH) inkrementell folgendermaßen erhöht:

  1.  HAUPT wird erhöht, wenn es API-inkompatible Änderungen gibt
  2. NEBEN wird erhöht, wenn es neue Funktionalitäten gibt, die aber noch mit der API kompatibel sind
  3. PATCH wird erhöht, wenn es Änderungen gibt, die ausschließlich Bugfixes umfassen.

Zu der Versionsnummer können noch Informationen für Build-Metadaten oder Vorveröffentlichungen wie z.b. pre-* hinzugefügt werden.

Einführung

Bei der Softwareentwicklung werden häufig viele Abhängigkeiten (Dependencies) für die eigene Entwicklung und das eigene Produkt benötigt. Das Aktualisieren dieser Abhängigkeiten kann sehr schnell extrem aufwändig werden, besonders dann, wenn die Abhängigkeitsspezifikationen zu strikt sind, oder die Versionierung nicht eindeutig ist. Es besteht die Gefahr des sogenannten „Version Lock“ (Ein Paket kann nicht aktualisiert werden, ohne alle anderen Pakete auch zu aktualisieren). Das Gegenteil ist die „Version Promiscuity“, ein Pakete, das zu viele alternative Versionen der Abhängigkeiten zulässt.

Ein einfaches Regelwerk, welches die Versionsnummern eindeutig definiert und ebenfalls bestimmt, wann eine Versionsnummer wie erhöht wird, kann diese Probleme minimieren. Dabei ist dieses Verfahren bereits relativ weit verbreitet. Egal auf welche Weise eine öffentliche API umgesetzt wird, es ist wichtig, diese übersichtlich und präzise zu definieren. Dies kann entweder durch den Code selbst, oder durch eine Dokumentation geschehen. Sobald die API veröffentlicht wurde, vermittelt man Änderungen durch die Versionsnummer im Format X.Y.Z. (HAUPT.NEBEN.PATCH). Bei der Implementation von Bugfixes, welche die öffentliche API nicht verändern wird nur die Z-Komponente inkrementiert. Bei API-kompatiblen Ergänzungen, die aber die API nach außen hin nicht verändern, wird die Y-Komponente erhöht. Wenn Änderungen vorgenommen werden, die die API inkompatibel zu früheren Versionen macht, so erhöht man die X-Komponente.

Dieses System heißt „Semantic Versioning“ oder Sematisches Versionieren.

Weshalb sollte ich Semantisches Versionieren nutzen?

Semantisches Versionieren ist keine revolutionäre Idee, du hast vermutlich bereits ein ähnliches System genutzt, oder Software gesehen, die ein solches System nutzt. Das Problem ist, das ähnlich nicht ausreicht. Ohne EInhaltung einer Spezifikation sind Versionsnummern fast nichtssagend. Denn dann kann ich über die Version keine Informationen über das Paket erhalten, von dem ich abhängig bin.  Hält man sich an die Regeln, und wird das auch bei den anderen Pakete getan, so kann man relativ einfach und ohne großen Aufwand seine Abhängigkeiten verwalten. Denn jede API-Änderung oder jeden Patch kann man sofort erkennen. Dadurch können auch relative Abhängigkeiten wie es wird eine Version größer oder gleich 3.1.0 aber kleiner 4.0.0 benötigt, ohne Probleme definiert werden.

Sollte das eigene Projekt sich an diese Regeln halten, so sollte man das angeben („This project uses Semantic Versioning“). Im README des Projekts kann man dann auf die offizielle Website verweisen, sodass auch Besucher die Regeln einsehen und verstehen können.

Genutzt werden kann Semantisches Versionieren z.B. bei Git-Projekten. Schau dir dazu auch mein Git-Cheatsheet an.

Frei nach: https://semver.org (Hier kann die Definition nachgelesen werden: https://semver.org/#semantic-versioning-specification-semver)