Versionierung

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

  1. Hauptversion
  2. Nebenversion
  3. Fehlerbehebung
  4. 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 Platformen 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 eingefrohren 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.


Wenn sich eine triviale Erkenntnis mit Dummheit in der Interpretation paart, dann gibt es in der Regel Kollateralschäden in der Anwendung.
frei zitiert nach A. Van der Bellen
... also dann paaren wir mal eine komplexe Erkenntnis mit Klugheit in der Interpretation!