Nächstes Release?

[Chris M.]

@jolt: Danke für's Angebot!

Den Branch gibt's schon (https://github.com/CometVisu/CometVi.../release-0.9.0), von daher ist develop eigentlich schon wieder frei

Womit Du spontan helfen könntest wäre Bug-Fixes von develop nach release-0.9.0 zu transferieren (nennt sich bei git wohl cherry-picking), das wollte ich schon machen. Da meine git-Kenntnisse aber relativ gering sind, stehe ich hier noch beim Stand Google-Recherche... Gerade an die Pull-Requests von starwarsfan habe ich dabei gedacht.

Der größte "showstoper" vor dem ersten Release Candidate ist das transferieren des Build-Skriptes. Das muss ich (leider) erst mal alleine machen. Ist aber nicht schwer und kommt sehr bald.

[starwarsfan]

Hallo miteinander

Den Branch gibt's schon (https://github.com/CometVisu/CometVi.../release-0.9.0), von daher ist develop eigentlich schon wieder frei

Ähm nein, nicht so richtig. Bzw. wäre es nicht gut, das im Sinne von Cherry-Pick so zu machen!

Womit Du spontan helfen könntest wäre Bug-Fixes von develop nach release-0.9.0 zu transferieren (nennt sich bei git wohl cherry-picking), das wollte ich schon machen. Da meine git-Kenntnisse aber relativ gering sind, stehe ich hier noch beim Stand Google-Recherche... Gerade an die Pull-Requests von starwarsfan habe ich dabei gedacht.

Es ist i.d.R. nicht schön bzw. für die Zukunft auch unpraktisch, Fixes via Cherry-Pick in einen Release-Branch zu holen! Das sollte nur dann gemacht werden, wenn der jeweilige Release-Branch nicht direkt etwas mit der Quelle der Fixes zu tun hat. Sprich, der develop ist der Hauptzweig, dort kommen alle Fixes/Changes/whatever hinein. Aus diesem Branch wird ein Release-Branch gemacht und von dort der Release gebaut. Das heisst, im Normalfall wird nichts mehr in einen Release-Branch hinein gemerget, weil das dann nicht getestet ist bzw. man dann mit dem kompletten Testing von vorn anfangen müsste. Gerade wenn man echtes CherryPicking macht kann es passieren, dass man nicht alles "erwischt" und man sich so einen (vom Code her) inkonsistenten Zustand einhandelt.

Hab's mir eben mal angesehen und m.M.n. wäre es (noch) problemlos möglich, den kompletten develop in den Release-Branch zu mergen. Grundsätzlich sollten alle Changes und Erweiterungen auf separaten Branches gemacht werden, welche dann zurück in den develop fliesen. Somit erfolgt direkt auf dem Develop keine Entwicklung um den Build des develop immer stabil zu halten. Mit Git ist das ja überhaupt kein Problem.

Ich will's mal so umreisen:

Entwicklung:

1. Feature- bzw. Bugfix-Branch vom develop machen
2. Entwickeln, testen, ...
3. Changes vom develop fetchen und in den Branch mergen (Stichwort: Rebase)
4. Entwickeln, testen, ...
5. Pull-Request machen, um den Branch in den develop zu mergen

Release:

1. Release-Branch vom develop machen
2. Mglw. notwendige Anpassungen für den Release machen (bspw. Versionsnummern korrekt setzen, Release-Notes etc.)
3. Release builden
4. Release-Branch zurück auf den develop mergen (kann mglw. entfallen, je nachdem, was in Step 2 passiert)
5. Versionseintrag des Release-Branch für einen potentiellen Bugfix-Release vorbereiten

Damit hat man den develop frei für die Weiterentwicklung und den Release-Branch startklar für einen eventuellen Bugfix-Release, unabhängig davon, ob im develop bereits neue Features begonnen wurden. Das heisst, wenn es einen Bugfix gibt, dann wird dieser wie gehabt auf einem separaten Branch gemacht und dann von dort in den develop und in den Release-Branch gemerget. Damit brauchts kein CherryPicking für sowas, sondern es kann einfach ein Bugfix-Release gebaut werden. Genau das wäre nämlich das Problem, wenn man einen Release aus dem develop bauen möchte, welcher begonnene Features noch nicht enthalten darf, weil diese noch nicht fertig sind.

Der größte "showstoper" vor dem ersten Release Candidate ist das transferieren des Build-Skriptes. Das muss ich (leider) erst mal alleine machen. Ist aber nicht schwer und kommt sehr bald.

Ich schliesse mich meinem Vorredner an, lass mich wissen, wie ich Dir helfen kann! Bei Fragen bitte fragen, obiges ist mein täglich Brot...

[starwarsfan]

Noch ein Nachtrag:

Einen richtigen neuen Release-Branch gibt es erst bei einem echten neuen Release. Also einem Release, welcher neue Features enthält! Somit wäre der aktuelle Release-Branch der 0.9.0. Dieser sollte sinnvollerweise besser 0.9.x heissen. Von dort kommt nun das Release 0.9.0, bei einem Bugfix das Release 0.9.1, 0.9.2 usw. Der nächste Release-Branch wäre dann 0.10.x bzw. wenn es soweit richtig gut ist die 1.0.x. Davon kommt dann die 1.0.0, 1.0.1 (Bugfix-Release) usw. usf.

[starwarsfan]

So, noch etwas drüber nachgedacht. Folgender Vorschlag nach obigem Schema:

• Aktuellen Release-Branch löschen
• Neuen Release-Branch Release-0.9.x anlegen (basiert somit auf dem aktuellen develop)
• Release 0.9.0 aus diesem Branch builden

Und damit von nun an:

• Bugfixes auf separaten Branches
• Mergen der Bugfixes in den Release-Branch und den develop
• Features auf separaten Branches
• Mergen der Features nur in den develop

Das hört sich auf den ersten Blick sicher kompliziert an, ist aber mit Git wirklich kein Problem. Man muss einfach mal mit dem Workflow warm werden, dann geht das von ganz alleine. Und wie gesagt, ich kann gerne dabei unterstützen!

[stBorchert]

Bzgl. des Branches für Releases und Entwicklung (speziell mit Feature-Branches!) empfiehlt sich auch ein Blick auf http://nvie.com/posts/a-successful-git-branching-model/.
Das (in leicht modifizierter Form) verwenden wir hier schon einige Zeit.

[jolt]

Wunderbar, ich freue mich extrem über die Diskussion, die hier gerade stattfindet.

@starwarsfan: Ich stimme dir zu 99.5% zu. Der aktuelle Workflow wie er hier praktiziert wird ist aber auch sehr nahe an deinem Vorschlag, insofern erwarte ich auch keine Probleme oder Widerstand.

Zwei kleine Anmerkungen hätte ich noch:

Das heisst, wenn es einen Bugfix gibt, dann wird dieser wie gehabt auf einem separaten Branch gemacht und dann von dort in den develop und in den Release-Branch gemerget. Damit brauchts kein CherryPicking für sowas, sondern es kann einfach ein Bugfix-Release gebaut werden.

Trotzdem musst du an einem Punkt entscheiden ob ein Pullrequest nur in develop landet oder auch in einem Release Branch. Für mich ist dass halt auch eine Art "CherryPicking". Wenn man aber die klassische Definition von CherryPicking zu Grunde legt, dann geben ich dir recht.

Genau das wäre nämlich das Problem, wenn man einen Release aus dem develop bauen möchte, welcher begonnene Features noch nicht enthalten darf, weil diese noch nicht fertig sind.

Unfertige Features gehören nicht in develop sondern einen Featurebranch. Das zugrunde liegende Problem bleibt natürlich trotzdem bestehen, denn in develop kann es durchaus (fertige) Features geben, die man dennoch nicht im Release Branch haben möchte.

Gerade wenn man echtes CherryPicking macht kann es passieren, dass man nicht alles "erwischt" und man sich so einen (vom Code her) inkonsistenten Zustand einhandelt.

Nur wenn du CherryPicking auf git commit Ebene betreibst. Ich denke Chris bezog sich hier auf git changeset / Pullrequest Ebene und da sollte so etwas eigentlich nicht passieren.

Meine Kommentare sind eher philosophischer Natur, im Grunde meinen und wollen wir alle das gleiche, also weiter machen bitte

[jolt]

• Aktuellen Release-Branch löschen
• Neuen Release-Branch Release-0.9.x anlegen (basiert somit auf dem aktuellen develop)
• Release 0.9.0 aus diesem Branch builden

Das ist nicht nötig. Damals unter CVS musste man leider so ein Vorgehen anwenden, da man in einer baumartigen Struktur gefangen war. Bei git ist man extrem frei bei der Erzeugung von Branches und der entsprechenden Changes darin. Ich würde daher dem Vorschlag von Chris folgen und den Branch Release spezifisch machen und auch explizit so nennen (0.9.0).

[starwarsfan]

Hi

Das ist nicht nötig. Damals unter CVS musste man leider so ein Vorgehen anwenden, da man in einer baumartigen Struktur gefangen war. Bei git ist man extrem frei bei der Erzeugung von Branches und der entsprechenden Changes darin. Ich würde daher dem Vorschlag von Chris folgen und den Branch Release spezifisch machen und auch explizit so nennen (0.9.0).

Nunja, kommt auf die Definition von "nötig" an.

Natürlich kann man von jedem beliebigen Stand ausgehend einen Branch aufmachen. Aber wozu? Um einen genauen Release resp. den Zeitpunkt festzunageln, werden Tags angelegt. Es macht keinen Sinn, für jeden Bugfix-Release einen eigenen Branch anzulegen. Auch wenn es unter Git extrem einfach ist, ist es schlichtweg unnötige Arbeit und unnötige Arbeit macht keiner gern.

Im Umkehrschluss wird das noch deutlicher: Angenommen, der jetzige 0.9.0-Branch wird released. Dann haben wir die Version 0.9.0. Jetzt kommt ein Bugfix, welcher zur Version 0.9.1 führt. Also haben wir zwei Varianten:

Variante 1: Vom aktuellen Stand des 0.9.0-Branch einen weiteren Branch abzweigen. Das wäre dann der Branch 0.9.1. Dort wird der Bug (oder auch mehre) gefixt und das ganze neu Released. Dann haben wir Release 0.9.1. Bei weiteren Bugfixes wiederholt sich das Spielchen.

Variante 2: Der Release-Branch ist im Namen generisch hinsichtlich der Bugfix-Version. Also gibts vom Branch 0.9.x das Release 0.9.0 und das wird getagt. Jetzt kommt ein Bugfix. Der geht direkt auf diesen Branch und es gibt das Release 0.9.1, welches wieder getagt wird. So gehts einfach weiter auf diesem Branch.

Zusammenfassung:
Wenn es eine Version 0.9.1 gab, macht der Branch 0.9.0 keinen Sinn mehr und kann gelöscht werden. Also warum erst einen weiteren Branch machen, wenn man das gleich auf dem ursprünglichen Branch erschlagen kann? Damit spart man sich das Anlegen des neuen Branch und das löschen des ursprünglichen Branch und zudem bleibt der Baum wesentlich übersichtlicher.

Es wäre eine schlechte Idee, beide Varianten zu mischen und auf dem Release-Branch 0.9.0 weitere Releases (0.9.1, 0.9.2, ...) zu bauen. Das überblickt keiner mehr und vor allem Aussenstehende checken es nur äusserst schwer denn der Branch heisst nunmal 0.9.0 und nicht 0.9.x.

Und so war meine Intention einfach die, den Branch-Name je Release generisch zu halten, um sich nicht unnötig Arbeit einzuhandeln. Selbst wenn das unter Git einfach ist.

[jolt]

Nunja, kommt auf die Definition von "Arbeit" an.

Einen Branch zu erzeugen oder zu löschen ist ein One Liner mit einer Laufzeit von Sekunden (anders als bei CVS). Ich sehe da nicht wirklich Arbeit. Ansonsten hast du recht, entweder Variante 1 oder 2, nicht mischen.

Wobei in Variante 1 der 0.9.1 Branch nicht zwingend ein Branch des 0.9.0 Branches sein muss. Ich kann die 0.9.1 auch direkt von develop branchen, wenn dort nur Bugfixes sind, die ich alle frei geben will. Diese Flexibilität gibt es in Variante 2 nicht.

Falls die Arbeit wirklich messbar sein sollte, würde ich behaupten wäre ein Release Branch ohne Versionsnummer ausreichend. Es wird so gut wie nie vorkommen, dass es ein 0.8.x Bugfix Update gibt wenn schon ein 0.9.x Update existiert. Dann müsste man deiner Argumentation folgend die Arbeit für 0.x Branches auch sparen und nur einen 0.x.y Branch anlegen.

Aber wie gesagt, das Ganze wird jetzt sehr theoretisch und im Grunde ist es mir egal. Derjenige, der die Arbeit macht soll entscheiden was er für besser hält und gut ist. Lasst uns die Energie lieber in praxisrelevante Ergebnisse stecken

[Dirk42]

Aber wie gesagt, das Ganze wird jetzt sehr theoretisch und im Grunde ist es mir egal. Derjenige, der die Arbeit macht soll entscheiden was er für besser hält und gut ist. Lasst uns die Energie lieber in praxisrelevante Ergebnisse stecken

... wobei ich Eure Diskussion sehr spannend finde - sie hilft mir Git etwas besser zu verstehen. Vielen Dank dafür! Vielleicht könnt Ihr das in einem eigenen Thread weiterdiskutieren, ich lese gespannt weiter mit

[Chris M.]

Ich hatte hier ein paar Tage nichts geschrieben, da ich das ganze zum Entwicklungs- und Release-Prozess erst mal in einer ruhigen Minute durchlesen und verstehen musste.
Am besten wir machen dazu im spezifischeren Thread https://knx-user-forum.de/forum/supp...quest-workflow weiter.

[starwarsfan]

Am besten wir machen dazu im spezifischeren Thread https://knx-user-forum.de/forum/supp...quest-workflow weiter.

Deswegen hat ihn jolt wohl auch aufgemacht.

[Chris M.]

So, das erste Test-Release der 0.9.0 ist nun verfügbar, vgl. https://github.com/CometVisu/CometVisu/releases
Die Versionsnummer ist 0.9.0-test1.

Hauptfokus dieses Test-Releases ist die Entwicklung des Release-Erzeugungsskriptes.

=> Wer Spaß am frühen Testen hat - nur zu!

Wer lieber etwas handfesteres will: den ersten richtigen Release Candidate wird's bald geben.

[jolt]

Womit Du spontan helfen könntest wäre Bug-Fixes von develop nach release-0.9.0 zu transferieren (nennt sich bei git wohl cherry-picking), das wollte ich schon machen. Da meine git-Kenntnisse aber relativ gering sind, stehe ich hier noch beim Stand Google-Recherche... Gerade an die Pull-Requests von starwarsfan habe ich dabei gedacht.

Ich bin alle Pull Requests seit dem Erzeugen des Release Branches durch und habe entsprechende Labels und Milestones verteilt. Mangels Berechtigung ging das leider nur als Kommentar, habe dir dazu auch eine Message schickt.

Alles mit Milestone == 0.9.0 müsste (falls noch nicht geschehen) durch den Code Review und dann in den Release Branch gemerged werden.

[Chris M.]

Der erste Release Candidate für die 0.9.0 ist da!

--> https://github.com/CometVisu/CometVi...tag/v0.9.0-RC1

Bitte viel und ausgiebig testen!

Mein Wunsch wäre eine Veröffentlichung in einer Woche, wenn keine Probleme gefunden werden.