-
Notifications
You must be signed in to change notification settings - Fork 91
ReleaseManagement
Auf dieser Seite werden die notwendigen Schritte zur Erstellung eines neuen Releases von SmartHomeNG beschrieben. Diese Schritte setzen auf dem Git Workflow Git-flow auf.
Bei einem Release sind die folgenden Schritte durchzuführen. Es sind grundsätzlich 3 Releasetypen möglich (Komplett Release, CORE Release und Plugins Release). Abhängig davon ist einer der beiden ersten Schritte (oder beide) auszuführen, gefolgt von den 3 weiteren Schritten.
Die Vergabeweise für Versionsnummern ist unter Versionsnummern beschrieben.
- Release Dokumentation vorbereiten
- Plugins Release von SmartHomeNG erzeugen
- CORE Release von SmartHomeNG erzeugen
- Neue Version der Dokumentation bauen
- Github Release/Tag erzeugen
- Release Kommunikation
Ein Workflow zum erstellen eines Releases ist auf der Seite Git-workflow(s)-für-SmartHomeNG ausführlich beschrieben. Dieser Workflow wurde bis zum Release 1.6.1 genutzt.
Der Workflow kann sowohl mit dem Kommandozeilen Tool git, als auch mit dem graphischen Client SoureTree durchgeführt werden. Eventuell ich es auch möglich andere graphische Clients hierfür zu nutzen. Das wurde jedoch nicht getestet.
Mit Release 1.7 kam ein vereinfachter Workflow zum Einsatz, der imp folgenden beschrieben ist. Dieser Workflow verzichtet auf einen extra anzulegenden Release Branch. Dieser Workflow ist im folgenden beschrieben.
- Release Notes für die Anwender Dokumentation schreiben/komplettieren (Text: Deutsch, Listen: Englisch)
- Bemerkungs-Block "Arbeitsstand" und leere Blöcke entfernen
- Release Notes für die Developer Dokumentation (Verweis auf Anwender Doku) erstellen und mit Datum versehen
- Release Datum in den Release Notes (User- und Developer-Doku) setzen
- Release Notes für das Blog (Verweis auf Anwender Doku) erstellen und mit Datum versehen (Bild + Kategorien setzen)
- Vorletzte Release Notes: "Wichtig" entfernen
- Plugins repository (develop): In __init__.py Version auf die Release-Version & branch auf 'master' setzen:
def plugin_release(): return '1.7' def plugin_branch(): return 'master'
- master branch auschecken
- develop branch mergen
- eventuell Plugins entfernen, die noch nicht "Production- Ready" sind und nicht mit in das Release kommen sollen
- committen & pushen
- develop branch auschecken
- Plugins repository (develop): In __init__.py Version auf 'nach Release' Version & branch auf 'develop' setzen:
def plugin_release(): return '1.7a' def plugin_branch(): return 'develop'
- committen & pushen
Damit ist das Plugin Release erfolgt und anschließend kann im develop Branch der Plugins bereits weiterentwickelt werden!
- Core repository (develop): In bin/shngversion.py Version auf die Release-Version & branch auf 'master' setzen:
# Update auf 1.6B wg. ÄNnderung bei RelativsPath Auflösung & Doku Änderungen # Update auf 1.7 wg. Release shNG_version = '1.7' shNG_branch = 'master'
- master branch auschecken
- develop branch mergen
- eventuell: Module und Libs entfernen, die noch nicht "Production-Ready" sind und nicht mit in das Release kommen sollen
- committen & pushen
- develop branch auschecken
- Core repository (develop): In bin/shngversion.py Version auf 'nach Release' Version & branch auf 'develop' setzen:
# Update auf 1.6B wg. ÄNnderung bei RelativsPath Auflösung & Doku Änderungen # Update auf 1.7 wg. Release # Update auf 1.7a wg. Kennzeichnung des Stands als "nach dem v1.6 Release" shNG_version = '1.7a' shNG_branch = 'develop'
- committen & pushen
Damit ist das Core Release erfolgt und anschließend kann im develop Branch des Core bereits weiterentwickelt werden!
Bei einem reinen Plugin Release ist es auch sinnvoll die Dokumentation neu zu bauen und zu veröffentlichen. Dabei wird zwar keine der Änderungen an den Dokuemntationsseiten aus dem Core übernommen, es werden jedoch Veränderungen an den Plugin Dokumentationen (und neue Plugins) in die Dokumentation aufgenommen.
- Das Skript
build_doc.sh
aus /doc aus dem master Branch in ein leeres Verzeichnis kopieren - Das Skript
build_doc.sh
mit der Option -m (Doku aus dem Master Branch bauen) starten - Dokumentation veröffentlichen (wichtig vor der Release Kommunikation, damit die Links zu den Release Notes nicht ins Leere laufen):
- Die Anwender Doku (das Verzeichnis html) aus work/user/build auf den Webserver kopieren und in user umbenennen
- bei Bedarf: Die Entwickler Doku (das Verzeichnis html) aus work/developer/build auf den Webserver kopieren und in developer umbenennen
- Release/Tag für den Core
- Auf https://github.com/smarthomeNG/smarthome auf 'releases' anschießend Button 'Draft a new Release' klicken
- Als 'Tag version' die Version (z.B. v1.7 @ Target: master) eintragen
- als 'Release title' SmartHomeNG Release v1.7 eintragen
- als Beschreibung einen Hinweis auf die Release Notes eintragen: Release notes are in the user documentation at https://www.smarthomeng.de/user/release/1_7.html
- Release/Tag für die Plugins
- Auf https://github.com/smarthomeNG/plugins auf 'releases' anschießend Button 'Draft a new Release' klicken
- Als 'Tag version' die Version (z.B. v1.7 @ Target: master) eintragen
- als 'Release title' Plugin Release for SmartHomeNG v1.7 eintragen
- als Beschreibung einen Hinweis auf die Release Notes eintragen: Release notes are in the user documentation at https://www.smarthomeng.de/user/release/1_7.html
- Blog Artikel veröffentlichen/freischalten
- Kurzen Artikel für das Forum mit Hinweisen zum Update Prozess und Verweis auf die Release Notes erstellen
- Artikel im Forum veröffentlichen (und "pinnen")
- Release Info auf gitter posten
- Im github Wiki in der Sidebar einen Link auf die Release Notes aus der Anwender Doku hinzufügen
Die aktuellen Release Notes und die Release Notes der zurückliegenden Versionen sind in der Dokumentation im Abschnitt Release Notes zu finden.