© rudall30/Shutterstock.com
Schneller Changelogs schreiben mit dem CLI-Tool Changelogger

Der Änderung auf der Spur


Keine Lust mehr auf ein Updatechaos in der Projektarbeit? Der Changelogger ist ein hilfreiches PHP-CLI-Tool, um einfacher Changelogs für Änderungen zu erstellen und diese in Git zu tracken.

Ich erinnere mich noch gut an meine Anfangszeit, in der ich dieses neue Medium Computer entdecken durfte. Eine Handvoll Disketten, später auch CDs, auf denen neue Programme für neue Abenteuer bereitlagen, durfte ich mein Eigen nennen. Und drohte sich der Spaß nach einem Jahr schon zu verflüchtigen, so pilgerte ich mit dem wenigen Taschengeld zum nächsten Computerladen und besorgte mir die neueste Version oder das Update.

Die Zeiten, in denen einmal im Jahr eine neue Version auf CD veröffentlicht wurde, sind inzwischen vorbei. Meine Apps werden nachts automatisch aktualisiert und auf dem Desktop informiert mich das Programm in der Regel selbst, dass ich ein Update zu installieren habe. Es vergeht kein Tag mehr ohne ein Update. Wer kann da noch den Überblick behalten? Als Anwender ist das in der Regel kein Problem. Updates beheben Fehler und bringen neue Features mit sich, aber als Entwickler kann das unter anderem komplizierter sein, manchmal sogar gefährlich. Hier müssen wir genau wissen, was und gegebenenfalls auch wie sich etwas geändert hat. Schließlich nutzen wir Software, um eigene Probleme zu lösen. Da ist es ärgerlich, wenn durch ein Update einer Bibliothek unser Produkt kaputt geht. Und das kommt öfter vor als man denkt.

SemVer

Wie können wir als Entwickler unsere eigene Software entspannt weiterentwickeln, ohne Angst zu haben, dass eine Abhängigkeit alles kaputt macht? Mit diesem Problem haben sich schon einige schlaue Köpfe beschäftigt. Tom Preston-Werner, Erfinder von Gravatar und Co-Gründer von GitHub, hat SemVer [1] ins Leben gerufen. Das steht für Semantic Versioning. Diese Spezifikation beschreibt, wie man Versionsnummern vergeben sollte. Und das geschieht nach einem ganz einfachen Schema: Jede Versionsnummer besteht aus drei Zahlen, die mit einem Punkt getrennt sind, zum Beispiel: Version 1.3.29. Die erste Zahl ist dabei die Major-Version, die zweite die Minor-Version und die dritte Zahl wird als Patch betitelt. Bei jedem Release wird eine neue Versionsnummer vergeben. Sollte ein Fehler behoben werden, der Backwards Compatible (BC) ist, dann wird die Patch-Nummer um eins hochgezählt. Major und Minor ändern sich dabei nicht. Sollte ein neues Feature hinzukommen, wird die Minor-Version erhöht und man setzt dabei die Patch-Version auf 0. Wird die Logik so geändert, dass sich das API bzw. das Verhalten ändert (Backwards Compatibility Breaks), wird die Major-Version erhöht und Minor und Patch werden beide auf 0 gesetzt.

Es gibt eine Ausnahme: Versionen vor 0.x.x, also bevor die erste Major-Version veröffentlicht wurde, sind von diesem Schema ausgenommen. Das heißt, während der Alpha- und Betaphase darf man die Minor- und Patch-Nummern anpassen und auch Funktionen ändern, ohne die Major-Version anzupassen. Schließlich ist die Software noch nicht fertig und in Entwicklung. Hier kann also alles passieren, und solche Software sollte man nicht in Production einsetzen. Dass das doch oft passiert, kann man leider nicht verhindern, in manchen Communities ist es fast schon zum Standard geworden.

Ist SemVer sinnvoll?

SemVer hat sich unter Entwicklern schnell verbreitet. Die Vorteile liegen auf der Hand: Man muss sich nur die neue Versionsnummer angucken und weiß sofort, ob man ohne Bedenken updaten kann. NPM, Composer und andere Dependency Manager setzen auf dieses Muster. In einer perfekten Welt würden sich alle Entwickler an dieses Schema halten und wir hätten keine Probleme. Viele halten sich leider nicht an SemVer. Das hat zur Folge, dass viele Dependency Manager nur bedingt gut funktionieren. Wir fangen dann an, Dependencies zu pinnen. Das heißt, dass Abhängigkeiten auf eine spezifische Versionsnummer festgeschrieben werden. Somit ist sichergestellt, dass auch immer Version x.y.z installiert wird. Allerdings muss man sich nun selbst um Updates kümmern und auch Patch-Versionen prüfen und manuell installieren.

Woran liegt das, dass wir als Entwickler uns nicht ans Schema halten, aber SemVer gleichzeitig gutheißen? Stephan Bönnemann hat dazu eine einfache Erklärung: Wir haben Angst, die Versionsnummer zu erhöhen. Laut Bönnemann gibt es im Deutschen sogar ein Wort dafür: Hauptversionsnummernerhöhungsangst [2]. Es wäre ein Leichtes, die Major-Versionsnummer anzupassen, aber oftmals wird es nicht getan. Wir sind noch viel zu sehr davon geprägt, dass eine neue Hauptversion mit vielen neuen Features, neuem Interface und natürlich einem Haufen Bugfixes daherkommt. ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang