Einheitliche Vergabe von Versionsnummern

Bei der Entwicklung von Themes und Plugins ist es notwendig, einen eindeutigen Versionsstand anzugeben. Anhand des Versionsstands und seines Formats kann beurteilt werden, ob die aktuelle Version für den produktiven Einsatz geeignet ist oder nur zu Entwicklungszwecken gespeichert wurde.

Für die Entwicklung an der FAU wurde daher folgendes Regelung getroffen, die für alle Themes und Plugins zum Einsatz kommen soll.

Die Versionsnummern des Themes werden mittels folgendem Verfahren gebildet:

• Erste Ziffer: Version des zugrunde legenden Designs. Damit diese Nummer wächst, müssten schon sehr grundlegende Dinge geändert werden.
• Zweite Ziffer: Aktuelle Milestone-Version. Ein Update mit großen neuen Features auf das CMS-System entspricht einem neuen Milestone. Viele Issues sind Milestones zugeordnet. Wenn alle Issues die zu einem Milestone gehören, gelöst sind, ist der Milestone erfüllt. Im GitHub kann man die Milestones und deren Status aufrufen.
• Dritte Ziffer: Fortlaufende Nummerierung, die einzelnen Commits von Änderungen in den jeweiligen Milestone entspricht. Jeder Commit sollte die Versionsnummer um eines erhöhen.

Beispiele

Version 1.8 RC 1

Dies entspricht dem ersten Release Candidat der Branch 1.8.

Version 1.8.9

Dies entspricht einer Version aus dem 1.8er Zweig, bei der es bereits zu 9 Änderungen kam. Es kann sich dabei auch um einen Release Candidaten handeln.

Branches

Die Entwicklung findet jeweils in Git-Branches statt. Entwickler und Designer committen ihre Änderung jeweils in einen Dev-Branch, der zu dem jeweiligen Milestone gehört, den wir gerade bearbeiten. Wenn alle wesentlichen für den Milestone vorgenommenen Issues abgearbeitet wurden, wird dann dieser Dev in den Beta-Branch germerged. (Anmerkung: „Mergen“ bedeutet, dass die Inhalte von zwei Versionslinien zusammengeführt werden. Üblicherweise werden dabei Änderungen in eine laufende Version übernommen.)

Vor dem Rollout einer neuen Version werden auch Testläufe durchgeführt. Diese finden auf dem Beta-Branch statt. Wenn die Änderungen „reif“ genug sind, werden sie Release Candidates genannt. Die Entscheidung, ob etwas als Release Candidat „fertig“ oder fehlerfrei genug ist, ist subjektiv.

Diese werden gesondert getestet. Tauchen Fehler auf, werden diese Fehler als Issue aufgenommen und hoffentlich behoben. Die Fehlerkorrekturen werden dann über den Dev-Zweig eingecheckt und danach mit Beta-Zweig gemergt. Es entsteht dann ein neuer Release. Bei den Release Candidats lässt man im Sprachgebrauch die Versionsnummer der Einzelcommits (die dritte Ziffer weg).

Wenn der Release Candidat als geeignet für den produktiven Betrieb gesehen wird, wird dessen Code in den „Master“-Branch gemergt. Der Master-Branch wird dann später auf den CMS-Systemen ausgerollt.

Über GitHub lässt sich eine grafische Abbildung abgerufen, die den Stand der Versionen und der Branches zeigt.

Anhand der Grafik lässt sich der Prozess der Entwicklung und des Ausrollens nachvollziehen.

Die Grafik zeigt drei miteinander verbundene Linien. Diese stehen für die jeweiligen Branches. Die grüne, untere Linie ist der aktuelle Entwicklungsbranch „dev1-8“. Alle Änderungen und Arbeiten der Entwickler und Designer werden in diesem Branch vorgenommen. Die Entwickler testen dazu auf eigenen Testservern oder ihren eigenen Arbeitsrechnern.
Die einzelnen Punkte auf den Linien entsprechen den jeweiligen Versionsupdates. Im Dev-Branch ist das stets die letzte Ziffer der Versionsnummer.

In der Grafik wurde zuletzt der „dev1-8“ Zweig in den „beta“-Zweig germerged. Diese wurde dann getestet. Als der Test ergab, dass keine bedeutenden Fehler auftrat und die neue Version zur Übernahme in den Produktivbetrieb geeignet war, wurde dieser Zweig dann wiederum in den „master“-Zweig gemergt.

Im „master“-Branch gab es dann nochmal ein Update. Dabei handelte es sich jedoch um keine wirksame Änderung, sondern um eine Anpassung der Versionsinformation.