Unter der semantischen Versionierung (eng. Semantic Versioning) versteht man ein eindeutiges Regelwerk zur Versionierung von Projekten.
Sie findet i. d. R. bei Softwareprojekten Anwendung und wurde auch hierfür entwickelt, kann aber auch z. B. bei abstrakten Dingen, wie der Definition eines Musters selber angewendet werden.
Meiner Meinung nach auch bei der Definition von Spielregeln ect.
Die semantische Versionierung (ab jetzt SV abgekürzt) eines Projektes, gibt den Projekterstellern sowie den Nutzern dieser Projekte, Vorteile.
Der Projektersteller hat klare Vorgaben, an die er sich richtet und muss sich keine Gedanken mehr über das Thema der Versionierung machen, zudem bietet er seinen Nutzern damit eine einfache Möglichkeit Vertrauen in die Versionierung des Projektes zu haben.
Der Nutzer hingegen erhält durch die SV eine eindeutige Aussage zur Kompatibilität des Projektes und können hier schon vorbereitende Maßnahmen treffen, ohne genau zu wissen, wie sich das Projekt in Zukunft weiterentwickeln wird.
Jetzt habe ich aber genug Vorteile genannt, ich wollte euch das Thema nur schon einmal schmackhaft machen.
Ich erkläre nun in groben Zügen, was SV ist und werde anhand eines Beispiels einige Eigenschaften dieser nennen.
Grundvoraussetzung ist eine präzise Definition einer öffentlichen Schnittstelle zur Interaktion mit dem Projekt. Bei Programmen spricht man von Programmierschnittstellen (APIs).
Die SV besteht hauptsächlich aus drei Elementen, welche durch einen Punkt voneinander getrennt werden.
MAJOR.MINOR.PATCH
Dabei werden alle Elemente durch natürliche Zahlen (inkl. Null) dargestellt, wobei es keine führenden Nullen geben darf.
Diese Zahlen werden bei einer Erhöhung des Elementes um eins inkrementiert.
z. B. 0 → 1 ; 5 → 6 ; 41 → 42
Es gibt noch zwei zusätzliche Elemente für Vorveröffentlichungen und Build-Metadaten, welche auch Buchstaben und Bindestrich beinhalten dürfen. Ich werde hier aber aus Gründen der Vereinfachung nicht weiter darauf eingehen.
Alle Versionen derselben MAJOR-Version sind in der API kompatibel zueinander.
MINOR und PATCH Änderungen müssen gewährleisten, dass sie kompatibel zur aktuellen API-Version sind, sonst sind sie MAJOR Änderungen.
Alle weiteren Aspekte werde ich nun anhand des Beispieles erklären.
Max Patternman hat von der Musterschuh-Meisterfabrik GmbH einen Auftrag erhalten ein Back-End Programm, für die Speicherung und Bereitstellung von Musterschuhdaten, zu schreiben (aka Datenbank).
Da Max Patternman clever ist, verwendet er zu Versionierung des Programms die semantische Versionierung.
Nach einer längeren Planungsphase und einer klaren Definition der API beginnt Max Patternman mit dem Schreiben des Codes in der Version 0.1.0.
In der Anfangsphase checkt er alle benötigten Funktionen ein und erhöht mit jeder neuen Veröffentlichung nur die MINOR-Version. (0.1.0 → 0.2.0 → 0.3.0 →… → 0.16.0 → 0.17.0)
Nach einer ausgiebigen Testphase veröffentlicht er die Version 1.0.0, da diese Version nun im produktiven Bereich eingesetzt wird.
Im Betrieb melden nun Mitarbeiter der Musterschuh-Meisterfabrik GmbH einen Fehler, der bei einer bestimmten Konstellation auftritt. Max behebt den Bug und stellt die Versionierung auf 1.0.1.
Herr Patternman wird beauftragt den Funktionsumfang zu erweitern, weil nun auch noch neue Eigenschaften abgespeichert werden sollen und hierzu neue Funktionen benötigt werden.
Die Version steht nun bei 1.1.0. (Beachtet, dass das PATCH-Element bei einem MINOR-Update wieder auf null gesetzt wird)
Durch die Neuerungen der Version 1.1.0 hat Herr Patternman festgestellt, dass die Funktion/Methode „eierlegendeWollmilchsau“ nicht mehr benötigt wird und später entfernt werden soll. Er stuft sie daher als veraltet (eng. deprecated) ein.
Es wird wieder eine neue Funktion gewünscht, daher 1.3.0.
Leider hat Herr Patternman sich zu sehr vom Druck des Managements beeinflussen lassen und die dringend nötigen Testklassen nicht geschrieben und somit funktioniert nun aus Versehen die API nicht mehr, sie ist „inkompatibel“ geworden.
Da keine vorhandene Version nachträglich verändert werden darf und die API-Kompatibilität wieder hergestellt werden muss, werden die Korrekturen unter der Version 1.4.0 veröffentlicht.
Ein Bugfix
Nach einigen Jahren meldet sich die Musterschuh-Meisterfabrik GmbH erneut bei Max Patternman, da das Datenbanksystem inzwischen komplett neue Anforderungen besitzt.
Diese Änderungen sind so umfangreich, dass sie zur alten API der Version 1.X.Y nicht mehr kompatibel ist. Daher wird nun die Version 2.0.0 verwendet. (Beachtet, dass die PATCH- und MINOR-Elemente bei einem MAJOR-Update wieder auf null gesetzt werden)
Ich hoffe, das Beispiel hilft die grobe Herangehensweise von semantischer Versionierung darzustellen und ich konnte euch überzeugen, in Zukunft auch bei Projekten, in denen es sich anbietet, SV einzusetzen.
Mich hat die SV vor allem wegen des sichereren Pinnings, also der Fixierung eine Software auf eine bestimmte Version, überzeugt.
Lest euch die Beschreibung der SV doch am besten einfach selber mal durch. (Geht flott)
Semantic Versioning 2.0.0 (DE)
https://semver.org/lang/de/ [Abgerufen am 18.03.2018]
Newman, Sam: Microservices : Konzeption und Design. Heidelberg: MITP-Verlags GmbH & Co. KG, 2015. -ISBN 978-3-958-45083-7. S. 97-98
Bei Fragen, gerne fragen.
VG Max
