6.4. Release erstellen

Dieses Seite enthält die Regeln und das Verfahren um ein neues Release zu erstellen.

Regeln

• Es findet keine aktive Entwicklung in dem master Branch statt. Nur im develop Branch oder besser noch, dedizierten feature_ Branches.

• Die Versionierung in der pom.xml folgt bedingt der Semantic Versioning Spezifikation.

• Bugfixes werden im develop Branch gemacht und in den master Branch cherry-picked. Sie erhöhen dort das Patchlevel um eins.

• Der Merge von dem develop Branch in den master erhöht die Minor Version um eins und setzt den Patch-Level auf 0 zurück.

• Der develop Branch hat immer eine Minor Version höher als der master plus -SNAPSHOTSuffix.

• Wenn eine neue Version auch Änderungen im Referenz-Theme benötigt, muss zuerst das Theme gemerged werden.

Veröffentlichen eines Releases

Zuerst muss entschieden werden warum ein Release erfolgen soll. Gründe sind:

• Eine neue Minor-Version weil der develop Branch gemerged wurde.

• Eine neue öffentliche Version weil ein Digest veröffentlicht wurde.

• Eine neue Patch-Level-Version weil ein Bugfix im master notwendig war.

Neue Minor-Version

Eine Minor-Version wird veröffentlicht, wenn neue Funktionalität als stabil angesehen wird und der develop Branch in den master gemerged wird. Wenn es auch Änderungen im Reference Theme gibt, müssen diese vorher gemerged werden. Danach wird das Release mit den folgenden Schritten erstellt:

Den develop Branch in den master Branch mergen:

cd goobi-viewer-core/goobi-viewer-core
git pull
git checkout master
git merge --strategy-option theirs develop

Nun wird die neue Version in der pom.xml gesetzt. Dort sollte zum Beispiel 21.01-SNAPSHOTstehen und typischerweise sollte es ausreichen, den -SNAPSHOT Suffix zu entfernen.

Anschließend die neue Versionsnummer in einer Variable speichern, commit, tag, push:

vim pom.xml
NEWVERSION="21.01"
git commit -am "release version ${NEWVERSION}"
git tag -a -m "release version ${NEWVERSION}" v${NEWVERSION}
git push --tags
git push

Am Ende muss die Minor-Version im develop Branch erhöht werden:

git checkout develop

In der pom.xml sollte zum Beispiel 21.01-SNAPSHOT stehen, dass zu 21.02-SNAPSHOTangepasst wird.

Commit und push:

vim pom.xml
git commit -am "prepare for next development iteration"
git push

Neue Patch Level Version

Eine Patch-Level-Version wird nur mit Bugfix veröffentlicht. Dafür werden die gewünschten Commits aus dem develop Branch cherry-picked. Am Ende wird in der pom.xml das Patch-Level erhöht. Das Release wird mit den folgenden Schritten erstellt:

cd goobi-viewer-core/goobi-viewer-core
git pull
git checkout master
git cherry-pick HASH1
git cherry-pick HASH2

Wenn das Patchrelease nicht für die aktuelle, sondern eine frühere Version erstellt werden soll, muss die frühere Version anstelle des masters als Branch ausgecheckt werden. Dazu das folgende Kommando verwenden: git checkout -b release21.01.1 v21.01.1

Nun die pom.xml editieren und den Patchlevel um einen erhöhen. Steht dort zum Beispiel 21.01 ist die neue Version 21.01.1

Anschließend wird die neue Versionsnummer in einer Variable gespeichert, commit, tag, push:

vim pom.xml
NEWVERSION="21.01.1"
git commit -am "release version ${NEWVERSION}"
git tag -a -m "release version ${NEWVERSION}" v${NEWVERSION}
git push --tags
git push

Wenn das Patchrelease in einem Theme verwendet werden soll, muss diese Version nach dem erfolgreichen Bauen und Veröffentlichen im Nexus in die pom.xml des Themes eingetragen werden.