Semantische Versionierung: Jeder sollte sie kennen!
Semantische Versionierung
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.
Elemente und Format der Semantische Versionierung
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.
Darstellung
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.
Bedeutung der einzelnen Elemente
- MAJOR (Magenta) – API kompatible Version
- MINOR (Orange)– Wird erhöht, wenn neue Funktionalitäten hinzu kommen
- PATCH (Hellblau)– Wird erhöht, wenn Fehler (Bugs) bereinigt werden
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.
Das Beispiel
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.
0.1.0
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.
0.2.0 – 0.17.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)
1.0.0
Nach einer ausgiebigen Testphase veröffentlicht er die Version 1.0.0, da diese Version nun im produktiven Bereich eingesetzt wird.
1.0.1
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.
1.1.0
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)
1.2.0
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.
1.3.0
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.
1.4.0
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.
1.4.1
Ein Bugfix
2.0.0
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)
Fazit
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)
Quellen
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
VG Max
Sau geil erklärt Max!
Jetzt ergibt das auch alles Sinn! :D Paar Lücken hatte ich da noch ^^
Hatte bei einem Spiel regelmäßig Patches gesehen, wobei die Firma dort des öfteren die Major-Version weggelassen hat, bis vor kurzem dann die 1.0.0 erschien mit neuer Engine und anderem Pi Pa Po.
Hast du sehr schon erkärt anhand der Beispielfirma Musterschuh-Meisterfabrik 😁
Könntest du demnächst mal erkären, wo sich Back-End und Front-End trennen quasi? Vereinfacht ist doch Front-End das ovaylay, das auch der Nutzer dann sieht und Back-End alles, was im Hintergrund passiert also der code und die Prozesse oder habe ich das falsch verstanden? Mein Informatikunterricht war vom Zeitaspekt her sehr kurz, dafür umso dürftiger im Inhalt!
Grüße
k3lda
Moin @k3lda,
haha danke.
Ich glaube, am Besten kann man das anhand einer Homepage erklären.
Das Front-End ist das Layout der Homepage mit den ganzen bunten Knöpfchen usw. Also das, was der Kunde zu Gesicht bekommt. Das Back-End hingegen speichert i. d. R. die Daten ab, auf die das Front-End zugreift.
Es muss nicht zu dieser strikten Trennung kommen, aber sie hat sehr viele Vorteile, wenn es darum geht, von meheren Personen genutzt zu werden.
Wenn du jetzt alleine eine Exceltabelle verwendest, ergibt eine Trennung kaum Sinn. Wenn du sie aber mit mehreren Teilen möchtest und alle gleichzeitig lesenden und schreibenden Zugriff haben sollen, denn sollte man diese Exceltabelle als Back-End auslagern.
Ich habe jetzt hier einfach wild losgeschrieben, ich hoffe, es ist verständlich. :P
VG Max
Mist, habe auf den Speedvoter Commi kommentiert :D
Ja ist verständlich, danke! :D
Also ist das Back-End, wenn es ausgelagert ist, wirklich nur die Datenbank? Also gehören die Formeln, die ich in die Zellen reinhaue nicht ins Back-End, sondern sind immer noch im Front-End? :)
This comment has received a 0.07 % upvote from @speedvoter thanks to: @maxpatternman.
sehr kreativ, resteem. Tatsächlich wäre das doch sicher interessant für jedes algorithmisierbare Projekt (wie Trainingspläne oder so). Wenn Person A bis zum Alter xx berühmt werden möchte, oder Fußballstar oder reich oder was auch immer Menschen so für Träume haben. Dann gibt es einen Basis Algorithmus den man verifizieren kann und Funktionserweiterungen aber auch Bugs zu Hauf. Oder kann man diese Analogie nicht ziehen?
Hallo @lauch3d,
Super! Vielen Dank :)
Ich mag Deine abstrakte Denkweise :D
Natürlich kann man dieses Regelwerk auch auf z. B. einen Lebensplan abstrahieren. Fände ich zwar ein wenig komisch, aber würde durchaus Sinn ergeben. Denn würde die API wahrscheinlich für das Lebensziel (bis zum Zeitpunkt X) stehen und falls man dieses Ziel nicht mehr erreichen kann oder sogar wechselt (heute Astronaut und morgen Fußballstar) würde man ein MAJOR-Update des Lebensplanes durchführen. Quasi Max 2.0.0.
Worin ich auch noch eine tolle Anwendung sehe, ist in Entwurfsmustern. Also man erstellt ein Muster für einen Fußballklub, der einen gewissen Standard hat und verwendet diesen denn einheitlich an mehreren Standorten. Ein gutes Beispiel hierfür sind Hackerspaces. Dort steht in den Design Pattern, dass man matehaltige Getränke (z. B. Club Mate) anbieten muss. Superlustig. :D
VG Max
habs gesehen und auch sehr funktionell mit der Mate :D
Natürlich nur für Bereiche in denen man maximal strukturiert sein muss um wettbewerbsfähig zu sein.
Ob Spekulation, Profi-Training, Vermögensaufbau (bzw. Lebenssicherung) dass ließe sich dann alles open source gestallten. Das ist ja systemtheoretisch auch alles Hacking. Dadurch kann ein 15Jähriger aus seinem Kinderzimmer oder ein Dorfverein aus Afrika genauso kompetitiv sein wie viele mit besseren Startbedingungen. UML ist ja auch zum Erfolg bei Nicht-Informatikern geworden weil es kommunikation ermöglicht. Naja ich werds mal versuchen. Kann ja nicht schaden wenn man so oder so unstrukturiert ist :D
Hab mir gedanken über Versionsnummern gemacht, aber schön das es andere gibt die es machen. ^^
Nun frage ich mich natürlich, wie es Firmen wie Nintendo schaffen, nach bereits einem Jahr auf Version 5 ihrer Switch Firmware zu kommen ohne neue Funktionen ^^ Naja, das wissen wohl nur die selbst.
Moin @oliver391,
Jetzt müsste man nur noch wissen, ob Nintendo bei den Firmwareversionen der Switch auch tatsächlich semantische Versionierung einsetzt. Ich habe das leider auf die Schnelle nicht herausfinden können.
Und falls doch, sagt die Version ja erstmal nur aus, dass die API inkompatibel zu den Versionen 4.X.Y, 3.X.Y usw. ist.
Es gibt ja noch deutlich mehr Möglichkeiten zu versionieren.
Semantische Versionierung eignet sich besonders für Bibliotheken und REST Paradigmen usw.
Ich werde sie auf jeden Fall viel häufiger einsetzen. :)
thx, super erklärt! ♥
This post has received a 1.25 % upvote from @drotto thanks to: @peppermint24.