Versionierung
« | 11 Jul 2020 | »Das für mich wichtigste Feature an SVN war die zentrale inkrementell hochgezählte Revisionsnummer, aus welcher man herrlich eine “Programmversion” bauen konnte.
Doch mit GIT also Versionskontrollsystem muss man sich etwas anderes überlegen.
Wie werden also Software Versionen für Releases erstellt?
Früher war alles einfach (mit SVN)
Besonders von Windows aber auch ganz allgemein kennen wir alle das Schema:
major.minor.patch.build, also
- Hauptversion
- Nebenversion
- Fehlerbehebung
- Fortlaufende Nummer pro Kompilat
major und minor Version definieren den “Feature-Level”, sollen also
Fortschritte bei der Funktionalität festlegen und das Patch-Level erhöht sich
bei jedem Neubau wegen einer Fehlerbehebung.
Eindeutig identifiziert wird jedes gebaute Produkt aber durch die Build-Nummer,
die Systeme wie SVN automatisch (und vor allem zentral) hochzählt.
Die Entwicklungsabteilung kann also ihre Arbeit machen und Releases mit einer
speziellen Build-Nummer bereitstellen, die dann getestet werden.
Läuft alles wie gewünscht erfolgt die Freigabe und man kann die Build-Nummer
einfrieren und später von diesem Stand aus neue Patches implementieren.
GIT ist eben anders
Fortlaufende Build-Nummern sind mit GIT unmöglich, da das Aufspalten und spätere Zusammenführen von Entwicklungsständen keinem linearen Schema folgt - es fehlt die zentrale Versionskontrolle. Somit hat jeder Commit zwar einen eindeutigen Hash-Wert, dieser ist aber nicht chronologisch sortierbar.
Anstatt dessen wird dem “Release-Management” aufgebürdet sich eine “passende” Versionsnummer auszudenken, die dann mit einem spezifischen Commit verknüpft wird. Man “tagged” also den Stand, den man mit einer Version verbinden möchte.
Aber wie sieht dieser Tag nun aus?
Eigentlich besteht er nur aus major.minor oder major.minor.patch
falls man einen Fehler ausbessern möchte.
Für mich bedeutet das aber, dass minor nun viel spezifischer darstellen
muss, was eine Software beinhaltet. Schließlich gibt es keine
chronologische Buildnummer mehr, die zwischen einem “alten” und “neueren”
Stand differenziert.
Das Status-Dilemma
Im GATE Projekt gibt es für mich aktuell keinen festen Entwicklungsplan
(leider), dennoch kann ich grob Feature-Wünsche nennen.
Bibliotheken unterscheiden sich von “einfachen” Programmen durch an anderes
Maß an Funktionalität. Dieses ist generischer und weniger konkret ausgeprägt,
als dies bei spezifischen Applikationen der Fall ist.
Eine Lib-Funktion nach dem Schema: “Kann mit XYZ Geräten kommunizieren” ist komplizierter zu vervollständigen also ein einfaches: “Hat einen Button um Gerät XYZ das Kommando ABC zu senden”.
Zweiteres ist nur eine Untermenge von ersterem.
Hinzu kommt außerdem, dass für mehrere Plattformen mehrere Implementierung notwendig sein können.
Eine mögliche inkrementelle Versionierung wäre dann als Summe aller implementierten Features möglich.
- Windows Filehandling
- Linux Filehandling
- Windows Messagebox
- X11/Linux Messagebox
würden zu einer Feature-ID oder Minor-Verison x.4 führen.
Eine Erhöhung der Major-Version würde dann den bestehen Featurestand
fixieren und Minor wieder bei Null weiterzählen lassen.
Ich überlege mir daher aktuell eine Art von Feature-Textdatei anzulegen,
aus der dann automatisch eine Versionsnummer generiert werden kann.
Dafür wäre es aber wichtig alle Änderungen und Feature-Updates mit
einer Überschrift zu versehen.
Das wäre auch gleichzeitig eine Historie, die jeder “Version” einen
Featurestand textual zuordnen könnte.
Es gäbe auch die Möglichkeit die Anzahl der Commits im Entwicklungszweig
zu zählen und daraus eine ID zu erstellen.
git rev-list --count master wäre ein solches Beispiel.
Ein solcher Commit-Counter könnte in einen Tag übernommen werden,
wenn ein Stand eingefroren wird.
Fazit
Kurz gesagt, ich weiß noch nicht so recht, wie ich hier weiter vorgehen werde. Aber eine Form der Versionierung wird auch im GATE Projekt notwendig werden.
Es ist schließlich auch für einen selbst wichtig den Fortschritt nachvollziehen zu können und die “Feature”-Zählung scheint mir für eine Bibliothek durchaus schlüssig.
Mal sehen ob sich das Schema für mich bewährt.
PS: Es bleibt natürlich die Frage offen, wann genau die Major-Version erhöht wird … aber das ist wie so oft rein “subjektiv” zu entscheiden.