Einheitliche Vergabe von Versionsnummern

Für alle am RRZE entwickelten WordPress-Themes und -Plugins verwenden wir ein einheitliches Schema zur Vergabe von Versionsnummern. Dadurch lassen sich Entwicklungsstände, veröffentlichte Versionen und Fehlerkorrekturen eindeutig nachvollziehen.

Die Versionsnummern orientieren sich an den Grundprinzipien der semantischen Versionierung und werden um eine zusätzliche Build-Nummer erweitert. Dieses Verfahren ermöglicht es, sowohl offizielle Veröffentlichungen als auch interne Entwicklungsstände eindeutig zu kennzeichnen.

Aufbau einer Versionsnummer

Eine Versionsnummer besitzt das folgende Format:

Major.Minor.Patch_Build

Beispiel:

2.5.3_17

Bestandteil	Bedeutung
Major	Grundlegende Änderungen oder inkompatible Anpassungen. Eine Erhöhung dieser Nummer erfolgt nur selten.
Minor	Neue Funktionen oder größere Erweiterungen, die weiterhin abwärtskompatibel sind.
Patch	Fehlerkorrekturen und kleinere funktionale Änderungen innerhalb einer Minor-Version.
Build	Fortlaufender Entwicklungsstand innerhalb derselben Patch-Version.

Die Build-Nummer hinter dem Unterstrich dient ausschließlich der eindeutigen Kennzeichnung einzelner Entwicklungsstände. Sie besitzt keine eigenständige Aussagekraft über den Funktionsumfang oder die Stabilität einer veröffentlichten Version.

Entwicklung und Releases

Während der Entwicklung entstehen zahlreiche interne Entwicklungsstände. Diese unterscheiden sich ausschließlich durch die Build-Nummer.

Ein typischer Entwicklungsverlauf sieht beispielsweise wie folgt aus:

2.5.3_0
2.5.3_1
2.5.3_2
2.5.3_3

Wird ein neuer produktiver Softwarestand erstellt, erhöht sich die Patch-Version und der Build-Zähler beginnt erneut bei 0:

2.5.4_0

Enthält eine Veröffentlichung neue Funktionen oder größere Erweiterungen, wird stattdessen die Minor-Version erhöht:

2.6.0_0

Nicht abwärtskompatible Änderungen führen zu einer Erhöhung der Major-Version:

3.0.0_0

Dadurch lässt sich jederzeit erkennen, ob es sich um einen internen Entwicklungsstand, eine Fehlerkorrektur, eine funktionale Erweiterung oder eine neue Hauptversion handelt.

Entwicklung mit Git

Die Entwicklung erfolgt grundsätzlich mit Git. Dabei unterscheiden wir zwischen Entwicklungsständen und produktiven Versionen.

Empfohlene Branch-Strategie

Für Projekte des RRZE wird grundsätzlich zwischen Entwicklungs- und Produktivzweigen unterschieden.

Branch `main`

Der Branch main enthält ausschließlich Versionen, die erfolgreich getestet wurden und für den produktiven Einsatz freigegeben sind.

Auf diesem Branch sollten sich jederzeit ausschließlich lauffähige und veröffentlichungsfähige Versionen befinden.

Branch `dev`

Die eigentliche Entwicklung erfolgt auf dem Branch dev.

Hier entstehen neue Funktionen, Fehlerkorrekturen und sonstige Änderungen. Versionen auf diesem Branch gelten als Entwicklungsstände und können noch unvollständig oder ungetestet sein.

Sobald die Änderungen erfolgreich getestet wurden und produktionsreif sind, werden sie in den Branch main übernommen.

Der empfohlene Ablauf lautet daher:

main
  ▲
  │ Merge nach erfolgreichem Test
  │
dev

Zusätzlicher Beta-Branch für größere Projekte

Bei größeren Projekten oder umfangreichen Änderungen empfiehlt sich eine zusätzliche Qualitätssicherungsstufe zwischen Entwicklung und Produktivbetrieb.

Hierfür wird ein weiterer Branch beta verwendet.

Der Ablauf sieht dann wie folgt aus:

main
  ▲
  │ Merge nach erfolgreicher Freigabe
  │
beta
  ▲
  │ Merge nach erfolgreichem Entwicklertest
  │
dev

Die einzelnen Branches übernehmen dabei folgende Aufgaben:

Branch	Zweck
`dev`	Laufende Entwicklung neuer Funktionen und Fehlerkorrekturen.
`beta`	Integration, Qualitätssicherung und Abnahmetests größerer Änderungen.
`main`	Freigegebene Versionen für den produktiven Einsatz.

Der Beta-Branch ist optional und empfiehlt sich insbesondere dann, wenn mehrere Entwickler gleichzeitig an einem Projekt arbeiten oder umfangreiche Änderungen zunächst gemeinsam getestet werden sollen.

Zusammenhang mit den Versionsnummern

Die Versionsnummer kennzeichnet den jeweiligen Entwicklungs- oder Veröffentlichungsstand unabhängig vom verwendeten Branch.

Typischerweise entstehen neue Entwicklungsstände zunächst im Branch dev. Nach erfolgreicher Qualitätssicherung werden diese in den nächsthöheren Branch übernommen. Erst Versionen auf dem Branch main gelten als offiziell freigegeben und für den produktiven Einsatz bestimmt.

Automatische Versionsverwaltung

Die Pflege der Versionsnummern erfolgt in den RRZE-Projekten automatisiert über den jeweiligen Build- und Release-Prozess.

Dadurch wird sichergestellt, dass sämtliche Versionsinformationen innerhalb eines Projekts konsistent bleiben und an allen erforderlichen Stellen identisch gepflegt werden.

Aus diesem Grund sollten Versionsnummern grundsätzlich nicht manuell in einzelnen Dateien angepasst werden.

Empfehlungen für externe Entwickler und Agenturen

Bei Entwicklungen im Auftrag des RRZE bitten wir darum, folgende Grundsätze einzuhalten:

Verwenden Sie das Versionsschema Major.Minor.Patch_Build.
Erhöhen Sie die Major-Version ausschließlich bei grundlegenden oder nicht abwärtskompatiblen Änderungen.
Neue Funktionen werden durch eine Erhöhung der Minor-Version gekennzeichnet.
Fehlerkorrekturen und kleinere funktionale Änderungen erhöhen die Patch-Version.
Die Build-Nummer dient ausschließlich der Kennzeichnung einzelner Entwicklungsstände und wird automatisiert verwaltet.
Entwicklungsstände, die noch getestet werden müssen, sollten ausschließlich auf dem Branch dev entstehen.
Für größere Projekte empfiehlt sich zusätzlich ein Branch beta, über den Integrations- und Abnahmetests erfolgen.
Erst erfolgreich getestete Versionen werden in den Branch main übernommen und gelten damit als produktiv freigegeben.
Versionsnummern sollten grundsätzlich nicht manuell in mehreren Dateien gepflegt werden, sondern ausschließlich über den vorgesehenen Projektprozess erzeugt werden.

Für die RRZE-Eigene Entwicklung verwenden wir verschiedene Skripte und Build-Anweisungen in unseren Repositorys, die ein Teil dieser Aufgaben automatisiert übernehmen. Bei Interesse daran, setzen Sie sich mit uns in Verbindung.