Was ist Semantic Versioning?
Semver ist eine Konvention, um die Versionsnummer einer Anwendung mit einer öffentlichen Schnittstelle zu vergeben. Auf die SemVer-Webseite findest du die Spezifikation. Hier erzähle ich dir den Teil, die für uns gerade relevant ist.
Eine Versionsnummer besteht aus drei Zahlen, die mit Punkten getrennt werden, zum Beispiel 3.5.2. Die erste Zahl ist die „Major Version“, die zweite Zahl die „Minor Version“ und die Dritte ist der „Patch Version“. Jeder dieser Zahlen wird eine Bedeutung zugesprochen und, wenn du eine neue Version der Software veröffentlichst, werden sie nach bestimmten Kriterien erhöht:
- Die Major Version wird geändert, wenn es Änderungen an der öffentlichen Schnittstelle der Anwendung gegeben hat. (Breaking Change)
- Die minor Version wird erhöht, wenn neue Funktionalität dazugekommen ist, welche keine Breaking Changes beinhaltet.
- Die Patch-Version erhöhst du, wenn Fehler korrigiert wurden.
Das ist eigentlich recht einfach, gehen wir davon aus das wir gerade die Version 3.6.2 haben und wir haben einige Änderungen implementiert und wollen ein neues Release veröffentlichen:
- Wenn Breaking Changes vorhanden sind, erhöhst du die Major Version. Das bedeutet, dass die neue Version 4.0.0 lauten wird.
- Wenn die Änderungen, Funktionalität hinzugefügt haben, ohne die öffentliche Schnittstelle zu verändern, erhöhst du die minor Version. Das bedeutet, dass die neue Version 3.7.0 heißen wird.
- Wenn wir du nur Bugfixes gemacht hast, dann erhöhst du die Patch Version. Das heißt so viel, wie dass die neue Version die 3.6.3 sein wird.
Auf dieser Art und Weise ist es auf Anhieb klar, welche Änderungen in eine neue Version reingekommen sind. Das ist wichtig damit unsere Verwender wissen, ob sie updaten müssen / sollen und mit welche Schwierigkeiten beim update rechnen sollten. Als Beispiel und aus der Sicht des Verwenders, wenn sich die Major Version geändert hat, dann weißt du, dass es Breaking Changes gibt und das kann ein gefährliches Pflaster sein. Das bedeutet, dass es klug wäre sich vor dem Update schlau, zu machen, um herauszufinden, was alles sich geändert hat, weil es eventuell notwendig ist, die eigene Software anzupassen. Ein weiteres Beispiel: Wenn sich die Patch-Version geändert hat, dann weiß du, dass Fehler korrigiert werden, also die Wahrscheinlichkeit ist groß, dass du den Patch installieren möchtest.
Und was hat das alles mit Conventional Commits zu tun?
Nun, wie bereits erwähnt, Conventional Commits ermöglichen uns, manche Aktionen zu automatisieren. Ein Beispiel dafür ist die Vergabe von neuen Versionsnummern, wenn wir Semantic Versioning verwenden. Du erinnerst dich bestimmt daran, dass als wir über Conventional Commits gesprochen haben, erwähnt haben, dass am Angang der Betreffzeile der Änderungstyp angegeben wird. Zwei der Änderungstypen, fallen besonders ins Auge: feat und fix. Dank diese beiden, wissen wir ob es sich bei der Änderung, um das Hinzufügen neue Funktionalität handelt oder ob wir lediglich einen Fehler korrigieren. Dank die BREAKING-CHANGE-Fußnote, bzw. das Ausrufezeichen in der Betreffzeile, weiß du, ob die öffentliche Schnittstelle verändert worden ist. Mit einem passenden Skript kannst du die Commit Historie, seit dem letzten Release durchforsten und anhand dieser Informationen, die Version erhöhen. Eine tolle Sache, nicht wahr?
