GitHub Repository mit Travis CI Unterstützung

[Chris M.]

Das Changelog dürfte auch relativ schwierig sein, da es ja Unterschiede zwischen neuen Features und Bug Fixes gibt. jolt wollte da mal was mit Tags automatisieren, glaube ich.

Zum Bump:
Die Idee ist gut - aber ich fürchte für uns zu kompliziert. Da müsste ich jedes mal nach der Syntax nachschlagen. Das alte Skript (vgl. https://github.com/CometVisu/_suppor...ake_release.sh ) hat einfach einen Kommandozeilen-Parameter übernommen, wo ich dumm doof einfach per Text die Versionsnummer festgelegt hatte. So etwas wäre hier auch schön - und wenn's nicht geht, dann ist's auch ok. (Wir sollten dann die Konfig-Dateien nur passend kommentieren, so dass alle 6 Monate zum Release offensichtlich ist, was wo gemacht werden muss)

Zum github-release Target:
Da müssen wir auch noch im Detail ran (oder rauswerfen und die Schritte per Hand auf der GitHub Webseite machen).

[peuter]

Zum Bump:
Die Idee ist gut - aber ich fürchte für uns zu kompliziert. Da müsste ich jedes mal nach der Syntax nachschlagen.

grunt bump --setversion=0.9.1

Ansonsten brauchen wir da nur patch/minor/major (und das alles jeweils mit "pre"-Präfix für Pre-releases) je nachdem welche Stelle der Versionsnummer geändert werden soll. Finde ich durchaus noch überschaubar, dokumentiert werden sollte das Ganze aber sowieso, egal welche Variante man nimmt, inkl. allen Schritten die für ein Release notwendig sind (außer wir bekommen das mit Grunt tatsächlich soweit automatisiert, dass es nur ein Befelh ist)

Zum github-release Target:
Da müssen wir auch noch im Detail ran (oder rauswerfen und die Schritte per Hand auf der GitHub Webseite machen).

Hatte ich nicht wirklich getestet, weil es da ja keinen "dry-run" gibt, mag also sein dass das nicht funktioniert, entweder teste ich das nochmal durch (was aber bedeutet, dass es ggf. viele "Release-Uploads" gibt bis es richtig funktioniert oder wir werfens raus.

[Chris M.]

grunt bump --setversion=0.9.1

Hatte ich schon probiert - ist aber am -RC1 (oder auch am -rc.1) gescheitert. Ich hatte dann aber nicht mehr wirklich tiefer an den Ursachen geforscht.

Hatte ich nicht wirklich getestet, weil es da ja keinen "dry-run" gibt, mag also sein dass das nicht funktioniert, entweder teste ich das nochmal durch (was aber bedeutet, dass es ggf. viele "Release-Uploads" gibt bis es richtig funktioniert oder wir werfens raus.

Es hatte schon irgendwie funktioniert. Aber nicht so wie von mir erwartet. Also gut möglich das noch hin zu bekommen. Aber:

Da wie in https://knx-user-forum.de/forum/supp...-weg-zur-0-9-1 geschrieben der RC1 draußen ist, würde ich vorschlagen im 0.9.1 Branch jetzt erst mal nichts mehr am Release-Skript zu bauen. Das würde ich für dieses Rease erst mal einfrieren.

[peuter]

Ok, dann schauen wir nach dem Release nochmal wo es hapert.

Dann beschäftige ich mich derweil mal damit, die Grundlagen für Unit- und Selenium-Tests zu machen. Damit wäre wir wieder beim ursprünglichen Thread-Thema. Mein Traum wäre es, dass Travis diese Tests bei zukünftigen PR mit ausführt und wenn wir bei den Tests einen möglichst hohen Wert der Code-Coverage erreichen, sollten wir damit eigentlich Regressionen ausschließen können (oder zumindest das Risiko minimieren).
An sich war die Intention dahinter aber die Grundlagen für ein mögliches Refactoring zu schaffen, also zumindest die Selenium-Tests sollen dann sicherstellen, dass danach noch alles so funktioniert wie vorher, Unittests muss man dann ggf. mit anpassen.

Und sollte das tatsächlich einen brauchbaren Stand erreichen, kann man als weitere Anforderung für Feature-PR's nur solche erlauben, die auch die entsprechenden Tests mitbringen (Plugins/Designs natürlich ausgenommen).