Release Freigabe Besprechung

[JohannMaierhofer]

Nachdem es bei der V2.8.23 Freigabe zu Diskussionen kam, schlage ich vor diese Diskussion zu verwenden um die Freigaben zu besprechen.
Hier könnte man besprechen wann wir wieder eine Release freigeben und welche PRs ggf. noch rein sollten.

Ich hätte auch gleich einen Vorschlag. Nachdem Jameica und Hibiscus schon bei einer 2.10, sind frage ich mich, ob wir nicht auch eine 2.10.1 als nächste Version nehmen sollten.
Wir haben gegenüber dem original JVerein so viele Fehler beseitigt und neue Features implementiert, dass wir uns durchaus von einer 2.8 absetzen können. Da wäre ja schon fasst eine 3.0 angebracht.

[BT-11]

Ich freue mich über eure tolle Arbeit und gebe aus Erfahrung den Hinweis die Versionsnummer Weise zu wählen. Meistens wird in Projekten ein Semantic-Versioning verwendet welches unter semver.org beschrieben ist. Nachfolgend ein Auszug in Englisch:
Summary
Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes

• MINOR version when you add functionality in a backward compatible manner
• PATCH version when you make backward compatible bug fixes

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format

leider bin ich gerade am Handy und kann hier nicht schön schreiben aber ich hoffe ihr versteht was ich meine

[JohannMaierhofer]

Danke für den Kommentar. Wenn das so üblich ist, sollten wird das vielleicht auch so machen. Ich habe gesehen, dass manche Projekte die ungeraden Nummern für Entwicklerversionen nehmen und die geraden für die offiziellen Releases.
Mit so einem Konzept wäre dann unser jetziges Nightly eine 2.9.0 und die nächste offizielle Release eine 2.10.0.
Noch sind wir ja rückwärts kompatibel. Ich denke das würde Sinn machen.

[dippeal]

1. Nach dem Major, Minor, Patch Grundsätzen zu arbeiten fände ich absolut richtig
2. Eine Version überspringen oder dev/official release Versionen zu erstellen halte ich für unsinnig, dafür gibt es die nightly
3. Korrekt wäre die nächste OpenJVerein Version 2.9.0
4. Entweder wir machen häufigere Releases, so dass auch Patches schnell ausgeliefert werden (Patch-Zahl erhöht sich) oder es kommen fast nur Minor Versionen zustande
5. Eine github action zur Bereitstellung eines offiziellen releases mit Upload zum gitbook und anschließendem PR für die nächste nightly Versionsnummer wäre denkbar

[JohannMaierhofer]

2. Eine Version überspringen oder dev/official release Versionen zu erstellen halte ich für unsinnig, dafür gibt es die nightly

Ich dachte ja, die Nightly mit ungeraden Nummern zu versehen. Wenn sich die jemand installiert kann er halt sehen, dass es ein nightly ist. Momentan bekommt er schon die nächste Version angezeigt und weiß später eigentlich nicht ob er jetzt ein nightly hat oder die offizielle Version.

Beispiele dafür sind Gimp, Darktable etc.

[dippeal]

Ich kann die Versionsnummer beim Erstellen des nightly, in der github action, ändern und z.B. ein Suffix anhängen. So wird daraus Beispielsweise "2.9.0-nightly".

[JohannMaierhofer]

Ich kann die Versionsnummer beim Erstellen des nightly, in der github action, ändern und z.B. ein Suffix anhängen. So wird daraus Beispielsweise "2.9.0-nightly".

Das ginge natürlich auch.

Ich habe noch nie direkt ein nightly installiert. Wie ist das denn da wenn man ein solches installiert hat. Bekommt man dann wenn die neue Release da ist eine Info, dass es eine neue Version gibt und man kann dann direkt online upgraden oder geht das nur wenn man eine offizielle Version hat?

[dippeal]

1. nightly werden manuell, aus dem github heruntergeladen und in den jameica Einstellungen > Plugins via Button "Plugin manuell installieren..." installiert.
2. Benachrichtigungen für Aktualisierungen & Auto-Update kann man im Selben Manu mit dem Button "Automatische Updates konfigurieren..." einstellen
3. Aktuell stehen nur die offiziellen Versionen als Plugin im OpenJVerein-jameica-repository zur Verfügung. Dort könnte man auch die nightly eintragen

Mit Suffix "-nightly" machen es auch die anderen Jameica Plugins:

[JohannMaierhofer]

Dann machen wir das doch so mit dem Nightly im Namen.
Offiziell zum Download anbieten muss nicht unbedingt sein.

[JohannMaierhofer]

@dippeal ich habe ja jetzt die Docu um die 2.9.0 erweitert.
Du könntest jetzt die 2.8.24 im Build durch 2.9.0 ersetzen.

[mbmueller]

4. Entweder wir machen häufigere Releases, so dass auch Patches schnell ausgeliefert werden (Patch-Zahl erhöht sich) oder es kommen fast nur Minor Versionen zustande

Man könnte Bugfixes von Features trennen und Bugfixes bspw. wöchentlich shippen (also als Patch-Version) und neue Features weiterhin unregelmäßig wenn es sich halt lohnt. Dadurch werden Fehler immer so schnell es geht behoben, es erscheinen aber nicht durchgehend neue Versionen, die den Nutzer verwirren könnten. Auch die Dokumentation muss für Bugfixes (idR) nicht angepasst werden.

Soweit ich weiß lässt sich auch das über Pipelines (halb-)automatisiert umsetzen. Ich selber kenne mich damit aber zu wenig aus, als dass ich das aufsetzen könnte.

[JohannMaierhofer]

Man könnte es so machen, dass man im Main Branch neue Features und Fehlerbehebungen macht so wie bisher.
Gleichzeitig würde man von der letzten Release einen Bugfix Branch erzeugen und in diesen nur Bugfixes mergen.

[mbmueller]

Man könnte es so machen, dass man im Main Branch neue Features und Fehlerbehebungen macht so wie bisher. Gleichzeitig würde man von der letzten Release einen Bugfix Branch erzeugen und in diesen nur Bugfixes mergen.

Das wäre auch eine Option. Man müsste dann halt entweder irgendwie dafür sorgen, dass Main immer auch up-to-date mit dem Bugfix-Branch ist

[dippeal]

Vorschlag: Man macht einen "feature" branch in den nur die neuen Funktionen rein kommen. Die Pachte kommen direkt in den main branch.
Der main branch bekommt immer die neue patch Version und könnte automatisiert bereitgestellt werden
Der feature branch würde bei Zeiten in den main branch mit neuer minor Version gemerged werden. Dann kann man auch "sprints" machen. featuer-branch1 beinhaltet Feature 1-3. feature-branch2 beinhaltet Feature 4-8. usw. Dann kann man auch von einander abhängige Features kapseln.

[JohannMaierhofer]

Meine Idee war schon, dass die Bugfixes auch im Feature branch (Main) korrigiert werden. Wahrscheinlich muss man die dann doppelt fixen, aber bei Bugfixes sollten die ja nicht so groß sein.
Dann wäre eben die Frage was in den Nightly builds sein soll. Ich dachte eben wie bisher auch die neuen Features. Das ist ja auch der Grund warum jemand ein nightly verwenden würde. Das könnte man dann weiter im Main erstellen.
Aus dem Bugfix Branch wird dann halt ab und zu eine Release produziert.

Wenn man das umdreht und die Bugfixes im Main hat, basieren dann die Nightly build auf Main oder werden die aus den Feature branches produziert?
Bei mehreren Feature branches sehe ich das Problem wie man erkennen soll ob die unabhängig von einander sind und wer die dann später mergen soll.
Wenn man im Feature branch auch bugs korrigiert braucht man bei der neuen Feature Release eigentlich nicht in den Main mergen sondern müsste den Main auf den Feature branch setzen.
Integriert man in diesen Vorschlag die Bugs nicht in den Feature branch müsste man für eine neue Version den Feature branch in den Main mergen müssen. Da stellt sich dann wieder die Frage wer das machen würde und evtl. die vielen Merge Konflikte beheben würde.

[dippeal]

Aufbauend auf deinen Vorschlag:

• Patche werden direkt in den main integriert und eine neues stable release 2.9.X erstellt und automatisch zum Update bereitgestellt
• Neue Funktionen werden in einen separaten feature branche gemerged
• Patch werden auch immer in den feature branche gemerged (ggf. automatisch)
• Wenn ein feature branch "fertig" (definition of done) ist wird er in den main mit neuer minor 2.X.0 gemerged
• Nightly builds wären dann der feature branch/minor release 2.X.0-nightly

Dann würde man mit einem feature branch arbeiten.

[JohannMaierhofer]

Wenn wir wirklich Bugfix Releases rausgeben, dann muss ich nochmal den Release Namen in der Docu ändern. Ich habe da jetzt 2.9.0 stehen. Da Bugfixes ja keine Features machen gilt die Doku auch für diese.
Dann sollte das in der Docu entweder 2.9.x oder einfach nur 2.9 heißen.

[mbmueller]

Dann sollte das in der Docu entweder 2.9.x oder einfach nur 2.9 heißen.

Wäre wahrscheinlich sinnvoll. Dann kann man auch die Regelung machen, dass alle Features die keine Anpassung der Dokumentation brauchen als PATCH laufen und alles was eine Dokumentation braucht kommt dann in eine MINOR.

[JohannMaierhofer]

MAJOR version when you make incompatible API changes

Ich hätte eine Frage zu den MAJOR Versionen. Was würde bei uns ein incompatible API change sein?

Ist das so zu verstehen, dass wenn man auf die neue Version umsteigt man danach nicht mehr auf eine alte Version zurück kann weil man inkompatible Datenbank Änderungen gemacht hat.

Oder bezieht es sich nur darauf, dass man evtl. alte Export Dateien nicht mehr importieren kann weil das Format geändert wurde.

Wenn der erste Fall gemeint ist, dann müsste die nächste Version eine 3.0.0 sein. Ich habe ja bei den Konten das Boolean Anlagenkonto durch ein Integer für die Kontoart ersetzt. Nach der Migration kann man nicht mehr zurück weil der alte Code das Anlagenkonto Flag abfrägt welches es nicht mehr gibt.

Ich könnte natürlich noch das Flag in der Datenbank lassen statt in der Migration zu löschen. Dann könnte man wieder zurückkehren wenn das bei allen anderen Migrationen die noch für diese Versionen gemacht wurden auch funktioniert.

[JohannMaierhofer]

Ich denke jetzt ist der richtige Zeitpunkt um über die Freigabe der 2.9.0 zu entscheiden.

Meiner Meinung könnte man die jetzt machen, evtl. noch den #600 reinnehmen. Die anderen gibt es ja schon mehrere Monate, sie scheinen also nicht so wichtig zu sein.

Wenn ich dann den Vorschlag vom 7. Dez. 2024 nehme, dann würde man die Version rausgeben und dann einen Branch für die 2.10.0 erstellen. Auf dem Main würden dann die 2.9.x als Bugfix Releases laufen. Die aktuellen PRs müsste man dann umstellen da sie nicht in den Main dürfen sondern in den 2.10.0 Branch. Bei Freigabe der 2.10.0 müsste diese dann in den Main zurück damit man dort die 2.10.x machen kann. Der 2.9.x Main Pfad wäre damit beendet.

Verstehe ich das richtig?

Aus meiner Zeit in der Entwicklung kenne ich das umgekehrt, da wird im Main mit 2.10.0 weiter gemacht und die 2.9.x kommt in den Branch. Dann muss man später die 2.10.0 bei Freigabe auch nicht zurück bringen. Die aktuellen PRs könnten dann auch bleiben. Da die Bugfix Branches wie 2.9.x nicht abgeschlossen werden könnte man sogar später noch Bugfixes für alte Releases machen.

Aber wenn das so dann mit den Freigaben der Bugfix Releases leichter ist können wir das natürlich auch wie vorgeschlagen machen.

[lenilsas]

Ganz genau habe ich das bei den Actions noch nicht angeschaut, aber meine Idee war zB. eine BearbeitenActon für viele verschiedene Views zu erstellen wo man die anzuzeigende View übergibt. Das gleiche mit Neu, Lösche und vielleicht auch noch andere. Dann könnte man viel Code sparen und es wäre leichter es einheitlich zu halten. Ob das so klappt weiß ich aber noch nicht.

[tolot27]

Mir ist auch aufgefallen, dass der automatische Formatter beim Speichern nicht so ganz funktioniert. Jedenfalls nicht so wie wenn man es selbst macht.

Das ist mir noch nie aufgefallen. Mir ist nur aufgefallen, dass er eigentlich nie aktiv ist, wenn ich einen bestehenden PR auschecke oder eine neue Branch basierend auf upstream/master erzeuge. Das liegt daran, das die Einstellungen dafür in einer settings-Datei gespeichert werden, die beim auschecken wieder überschrieben wird.

[tolot27]

Mir ist auch aufgefallen, dass der automatische Formatter beim Speichern nicht so ganz funktioniert. Jedenfalls nicht so wie wenn man es selbst macht.

Das ist mir noch nie aufgefallen. Mir ist nur aufgefallen, dass er eigentlich nie aktiv ist, wenn ich einen bestehenden PR auschecke oder eine neue Branch basierend auf upstream/master erzeuge. Das liegt daran, das die Einstellungen dafür in einer settings-Datei gespeichert werden, die beim auschecken wieder überschrieben wird.

Ne, da wird nix überschrieben. Es sind gar keine projektspezifischen Einstellungen für den CF konfiguriert.

[lenilsas]

Mir ist nur aufgefallen, dass er eigentlich nie aktiv ist, wenn ich einen bestehenden PR auschecke oder eine neue Branch basierend auf upstream/master erzeuge. Das liegt daran, das die Einstellungen dafür in einer settings-Datei gespeichert werden, die beim auschecken wieder überschrieben wird.

Das hatte ich anfangs auch, es kommt darauf an wo man den Formatter einstellt. Irgendwie blicke ich da bei Eclipse auch nicht ganz durch welche Einstellungen für das Projekt gelten und welche allgemein.
Wenn wir den Code formatieren können wir ja auch gleich die Einstellungsdatei mit in Git nehmen damit es bei djedem der es neu einrichtet automatisch richtig eingestellt ist.

[tolot27]

Das addressiere ich gerade mit #608, wie du ja schon gemerkt hast. 😄

[dippeal]

Können wir das Formatierungs-Thema auslagern und wieder zur Releasebesprechung zurück kommen?
Code Formatter kann man wahrscheinlich mit einer github action erschlagen: Code checkout > format > einchecken.

@JohannMaierhofer Inkompatible API Änderung kann sowas sein wie: Schnittstellen die Funktionen nicht mehr anbieten, DB Anpassung, Abhängigkeit von anderer Software (Jameica, Hibiscus), Export/Import von Backups/Dateien. Je nach Umfang und Auswirkung der Änderung sagt ein Releasemanager ob es sich um eine Major oder Minor Version handeln muss. Vielleicht kann jmd die Rolle des Releasemanagers übernehmen?
Üblicherweise macht man eine Major Version mit Ankündigung, da es wegen der Inkompatibilität auf die vorherige Version kein Zurück gibt.

Ich bin auch dafür einen PR zu wählen und nach diesem das major Release 3.0.0 zu erstellen. #600 scheint mit geeignert, könnte aber auch jetzt schon gemacht werden.

• Der 2.9.0 wird ein Archiv Branch, da er ja eigentlich schon der 3.0.0 ist
• Der 3.0.0 wird der neue master brach
• Ein Branch 3.1.0 wird erstellt in den Features reinkommen (automatische nightly)
• Github action für Patche 3.0.x werden in 3.1.x automatisch übernommen (sollte gehen, da der 3.0 Code ja in 3.1 enthalten ist)
• Github action für automatische release-Erstellung von 3.0.x (da Patche unkritisch bzgl. Kompatibilität sind)
• Irgendwann wird 3.1.x in den master gemerged, ein release erstellt und 3.2.0 erstellt

[dippeal]

1. Doku anpassen: Ja
2. Link in oJV anpassen: Ja und ja vor dem 3.0 release
3. Sollte es 3.1.0 heißen: Ja. bugfixes (plural) werden in 3.0.1 (neuer master nach 3.0.0 release) eingespielt und per action in 3.1.0 (feature branch) gemerged. Irgendwann wird dann 3.0.1 released und 3.0.2 erstellt. Bugfixes für 3.0.2 werden per action in 3.1.0 eingespielt. Und so weiter...
4. Der feature branch muss in den master gemerged werden. Entweder mittels "merge --strategy=ours master" oder "reset --hard feature_branch". Es gibt sonst nur die Einstellung default branch, aber das ist hierfür nicht das Richtige.
5. Beim erstellen eines PR muss man dann angeben ob in den master (fix) oder in den feature branch gemerged werden soll

[JohannMaierhofer]

Ok, ich verstehe das. Ich kenne mich nur mit Git nicht so aus, darum war mir nicht klar wie man den Branch wieder zu Main macht. Ich habe mir mal ein Bild gezeichnet mit den zwei Optionen. Die erste ist dann wohl das, was wir machen.

[dippeal]

Alles gut und korrekt. Oberen Vorschlag würde ich präferieren.

[JohannMaierhofer]

Ja. bugfixes (plural) werden in 3.0.1 (neuer master nach 3.0.0 release) eingespielt und per action in 3.1.0 (feature branch) gemerged.

Kann es vorkommen, dass es dabei Merge Konflikte gibt und wie löst man die dann auf?

Es kann ja sein, dass der Code in 3.1.0 so verändert wurde, dass der Fix jetzt nicht mehr direkt passt.

[dippeal]

Hi Johann,
klar kann das passieren. Dann gibt es nur 2 Möglichkeiten, händisch anpassen damit es zum neuen 3.1 code passt oder verwerfen.

[JohannMaierhofer]

Wegen der Jameica Abhängigkeit. Was machen wir dann mit #409. Damit der richtig funktioniert brauchen wir die neue Jameica.
Darum dachte ich, dass User, die diese nicht habe die neue JVerein Version nicht automatisch bekommen.
In der Release Note würden wir dann schreiben, das man eine neue Jameica Version braucht damit man JVerein automatisch bekommt.

Aber ja, ganz schön ist das auch nicht wenn wir die User zum Jameica Umstieg zwingen.

Was machen wir dann mit #409. Ich sehe da zwei Optionen:

• wir schliesen ihn und machen ihn einfach gar nicht, bei der nächsten Release hätten wir ja sonst wieder die gleiche Diskussion
• oder wir nehmen ihn auch ohne den Jameica Fix rein und beschreiben in der Release Note den bestehenden Fehler und dass man ihn mit einem Update von Jameica beheben kann

[dippeal]

Wegen der Jameica Abhängigkeit. Was machen wir dann mit #409. Damit der richtig funktioniert brauchen wir die neue Jameica. Darum dachte ich, dass User, die diese nicht habe die neue JVerein Version nicht automatisch bekommen. In der Release Note würden wir dann schreiben, das man eine neue Jameica Version braucht damit man JVerein automatisch bekommt.

Aber ja, ganz schön ist das auch nicht wenn wir die User zum Jameica Umstieg zwingen.

Was machen wir dann mit #409. Ich sehe da zwei Optionen:

• wir schliesen ihn und machen ihn einfach gar nicht, bei der nächsten Release hätten wir ja sonst wieder die gleiche Diskussion
• oder wir nehmen ihn auch ohne den Jameica Fix rein und beschreiben in der Release Note den bestehenden Fehler und dass man ihn mit einem Update von Jameica beheben kann

Möglichkeit 3: Für release oJV 4.0 vormerken und dann die neue Jameica Version voraussetzen.

[lenilsas]

Ist es nicht auch möglich im Code die Jameica Version zu testen und jenachdem den richtigen Code auszuführen?
Dann könnte man in die Releasenotes schreiben, dass es das Future nur mit dem aktuellen Jameica gibt.
Beim Syntax-Export habe ich es auch so gemacht.

[JohannMaierhofer]

Das geht natürlich auch, dann planen wir das mal für die V3.1.0 nachdem die 3.0.0 draußen ist.

[lenilsas]

Wie sieht es mit dem neuen Releas aus? Warten wir noch auf #600? Ist der bald abgeschlossen? Ich selber kann den leider nicht reviewen da ich kein Mittelverwendung mache und grade keine Zeit und Kraft habe mich da reinzudenken.
Wenn das noch länger dauert sollten wir evtl. Schon vorher den Release machen, da ja viele Fehlerbehebungen drin sind auf die die Nutzer warten.

[JohannMaierhofer]

Ich baue bei #600 heute noch den Dialog zum Setzen der Startwerte ein. Es wäre natürlich gut wenn der noch reinkommen würde.
Wenn aber außer tolot keiner mehr reviewen kann dann sollten wir ihn rauslassen. Ich denke auch, dass wir wegen der behobenen Fehler schnell eine neue Version rausgeben sollten.
Wenn #600 nicht reinkommt würde ich die Migration von #617 ändern, so dass wir den noch reinnehmen können. Das ist ja einer der Gründe für die 3.0.0.

[mbmueller]

Mit der Mittelverwendung habe ich leider auch keine Erfahrung.

[JohannMaierhofer]

Das Umstellen auf NewAction und EditAction wäre natürlich auch noch vorteilhaft. Da wir dann zwei Branches haben würde es wohl weniger Probleme geben die Bugfixes in den Feature Branch zu mergen. Wenn die Actions erst im Feature Branch kommen sind sie halt nicht im Bugfix Master und der Code würde sich doch an einigen Stellen unterscheiden.

[JohannMaierhofer]

Ich hätte jetzt noch eine Idee wie wir mit #600 weiter machen könnten.

Wenn @tolot27 sein approve gibt könnte ein anderer ohne Testen zustimmen. Dann nehmen wir es rein und in der Release Note erklären wir es als Experimentelles Feature mit der Bitte an die Anwender eine Rückmeldung zu geben. Bei positiven Rückmeldungen ändern wir dann später den Status bzw. nehmen Korrekturen vor.

Wenn sich bei uns niemand damit auskennt können wir das ja nur über die Anwender machen.

Da wird es doch einige geben, die zu so einer Rechnung verpflichtet sind. Die könnten prüfen ob JVerein zum gleichen Ergebnis kommt wie ihre heutige Berechnung.

[JohannMaierhofer]

Ich glaube wir haben jetzt einen Stand um die 3.0.0 herauszugeben.

Es müsste nur noch ein zweiter den #600 approven damit wir den erwähnten Vorschlag mit dem experimentellen Feature gehen können. Der #600 sollte ja noch rein kommen.

[dippeal]

Viel Erfolg mit dem Mittelverwendungsreport - review erteilt.

[lenilsas]

Wollen wir jetzt das neue releas machen. Sonst kommen immer noch neue pes rein und es verzögert sich weiter. Wir können ja sonst auch bald noch einen machen wenn es so viele Neuerungen gibt.

[JohannMaierhofer]

Ja wir sollten jetzt die 3.0.0 machen. Wer macht es?

[dippeal]

Nach #651 teste ich noch mal weiter und wenn keine Probleme entstehen können wir gerne 3.0.0 rausbringen.

[dippeal]

Release 3.0.0 habe ich soeben veröffentlicht: https://openjverein.github.io/

[JohannMaierhofer]

Dankeschön

[tolot27]

Ist ein richtig umfangreiches Release mit vielen neuen und wichtigen Features geworden! Vielen vielen Dank für die tolle Arbeit! 😄💪

[tolot27]

Eine bugfix branch kann man von basierend von einem Tag erzeugen, indem man in Github erst im Branch-Menü den Tag auswählt und dann im zweiten Durchgang im Branch-Menü einen neuen Namen (bugfix-x.y.z) eingibt und dann auf "Create branch bugfix-x.y.z from " klickt. Siehe auch Creating and deleting branches within your repository.
Idealerweise erhöht man dann gleich mit dem ersten Commit die Version in der plugin.xml.
Der eigentliche Bugfix sollte dann basierend auf der neuen Branch erzeugt werden, nicht basierend auf master. Das geht, indem man die bugfix branch auscheckt oder ein git rebase <bugfix branch name> auf seiner bereits vorher erzeugten lokalen branch macht.

[lenilsas]

Müssen wir für jeden Bugfix Version einen neuen Branch machen? Ich denke man sollte die meisten Bugfixes direkt releasen (D.h. einen neuen Tag erstellen), damit wäre der Branch aber jeweils nach einem Commit tot. Wäre es da nicht sinnvoller einen Branch bugfix-3.0.x (wirklich x) zu erstellen in dem alle Bugfixes der 3.0.0er Version landen?

[tolot27]

Müssen wir für jeden Bugfix Version einen neuen Branch machen? Ich denke man sollte die meisten Bugfixes direkt releasen (D.h. einen neuen Tag erstellen), damit wäre der Branch aber jeweils nach einem Commit tot. Wäre es da nicht sinnvoller einen Branch bugfix-3.0.x (wirklich x) zu erstellen in dem alle Bugfixes der 3.0.0er Version landen?

Ja, müssten wir. Momentan sieht es vielleicht etwas seltsam aus, wenn nur ein commit (falls squashed) in einer branch ist. Es können jedoch durchaus auch mehrere Commits aus mehreren PRs sein, bis der bugfix irgendwann released wird (kann mal mehrere Tage dauern).

[JohannMaierhofer]

Ich verstehe jetzt die Diskussion nicht ganz. Das wurde oben schon diskutiert und es gab keine Kommentare.
Die Vorschläge waren:

• Auf dem Main wird weiter entwickelt mit neuen Features und den Nightlies so wie bisher. Dann gibt es den 3.0.x Branch wo nur Bug Fixes gemacht werden. Dort wird dann 3.0.1, 3.02 etc. produziert. Das hätte ich am einfachsten gefunden
• Der andere Vorschlag war die neuen Features in einem 3.1.0 Branch zu entwickeln und dafür auf dem Main die Bugfixes zu machen. Dort gibt es dann eben die 3.01, 3.02 etc. Damit gibt es aber keinen Branch für die Bugfixes, die sind halt auf dem Main

Siehe dazu auch mein Bild vor 2 Wochen. Da hat keiner kommentiert und dann kann es dippeal so machen wie er wollte. Ich kann mit beidem leben.

Und warum sollte man jetzt für jeden Bugfix einen Branch machen. Wir sammeln halt Bugfixes auf dem Main und geben ab und zu eine Bugfix Release raus.

[tolot27]

Oh, tolle Grafik. Ich hatte zu der Zeit zu viele Mails und habe nicht so aufmerksam hier gelesen. Das Problem mit bugfixes in master ist, dass dann wirklich nur bugfixes darein gemerged werden dürfen. Das müsste ziemlich diszipliniert erfolgen, bis das nächste feature release gemacht wird. Üblicherweise wird eigentlich master sogar als protected branch geführt. Wir können es ja mal so versuchen.
Ein Vorteil von Bugfix branches ist allerdings, dass man sie zu jederzeit in jede beliebige andere Branch mergen kann ohne ein rebase machen oder komplett master mergen zu müssen. Man könnte natürlich auch cherry-picking der bugfix commits machen. Da darf man dann jedoch keinen commit übersehen.

[dippeal]

Kein bugfix branch. Viel zu stressig.

[dippeal]

Da der #655 schon wichtig ist, würde ich gerne die 3.0.1 releasen. Jemand was dagegen?

[JohannMaierhofer]

ja, releasen

[dippeal]

Erledigt

[lenilsas]

Danke!

[JohannMaierhofer]

Ich glaube, wir sollten die 3.0.2 jetzt herausgeben.

[lenilsas]

ja, finde ich auch. @dippeal kannst du das wieder machen?

[dippeal]

ja, finde ich auch. @dippeal kannst du das wieder machen?

ja

[dippeal]

Erledigt

[JohannMaierhofer]

Danke

[tolot27]

Für ein besseres Branch- und Nighly-Build-Management schlage ich folgende Punkte vor:

• Einführung einer neuen Branch-Nomenklatur
  • Einführung der Branches "next-major", "next-minor" und "next-hotfix", statt "feature-x.y.z"
  • zukünftige lokale Feature-Branches im eigenen Fork haben den Präfix "feature/"
  • zukünftige lokale Bugfix-Branches im eigenen Fork haben den Präfix "bugfix/"
  • (zukünftige lokale Patch-Branches im eigenen Fork haben den Präfix "patch/")
• intensive Nutzung von git rebase bei den jeweiligen Branches; das Konfliktmanagement ist identisch zu git merge
• automatisches mergen bzw. rebasen von Bugfix-Branches nach "next-hotfix", nachdem die jeweiligen PRs in master gemerged wurden.
  • Hier könnte man überlegen, ob man die Hotfixes nicht gleich automatisch erzeugt, da es ja nicht umsonst Hotfixes sind.
• automatisches rebasen von "next-minor" nach "next-major", wenn ein Feature-PR gemerged wurde. Damit braucht man keine PRs für merging von Features nach next-major.
• (automatisches) Erzeugen von Tags bei Releases (minor, major, hotfix)

Die Branch-Präfixe haben den Vorteil, dass man die Automatisierung mit den GitHub Actions leicht bewerkstelligen kann. Um momentan automatisiert ein nightly auf der aktuellen feature branch zu erstellen, muss man entweder die aktuelle Versionsnummer tracken (woher ohne auszuchecken?) oder hoffen, dass keine Tippfehler in den branch names sind und man mit git branch -a --sort=-committerdate --no-merged master --list "feature-*" | sort -V | head -n 1" die richtige nächste feature branch bestimmen kann.

[lenilsas]

Für ein besseres Branch- und Nighly-Build-Management schlage ich folgende Punkte vor:

• Einführung einer neuen Branch-Nomenklatur

  • Einführung der Branches "next-major", "next-minor" und "next-hotfix", statt "feature-x.y.z"
  • zukünftige Feature-Branches haben den Präfix "feature/"
  • zukünftige Bugfix-Branches haben den Präfix "bugfix/"
  • (zukünftige Patch-Branches haben den Präfix "patch/")

Sind wirklich so viele Branches nötig? Ich fände es gut, wenn wir dabei bleiben, dass master der Bugfix-Branch ist und es dazu jeweils einen feature Branch für jede Version gibt. Den kann man natürlich so benennen, dass er von den Actions einfacher identifiziert werden kann. Mehr Branches braucht man meiner Meinung nach nicht.

• intensive Nutzung von git rebase bei den jeweiligen Branches; das Konfliktmanagement ist identisch zu git merge

Was ist der Vorteil von rebase? Ich kenne mich da nicht so genau aus, lokal verwende ich das schon, aber bei upsream Branches habe ich es bisher nie eingesetzt.

• automatisches mergen bzw. rebasen von Bugfix-Branches nach "next-hotfix", nachdem die jeweiligen PRs in master gemerged wurden.

warum soll man Bugfix Branches und "next-hotfix", haben? Das ist doch quasi das gleiche. Momentan kommen alle Bugfixes nach master und wenn nötig wird da ein bugfix Release erstellt, dafür ist doch kein extra Branch nötig.

• Hier könnte man überlegen, ob man die Hotfixes nicht gleich automatisch erzeugt, da es ja nicht umsonst Hotfixes sind.
• automatisches rebasen von "next-minor" nach "next-major", wenn ein Feature-PR gemerged wurde. Damit braucht man keine PRs für merging von Features nach next-major.

Ich denke die meisten Änderungen sind minor, wenn dann eine größere Änderung gibt geben wir ein major statt des nächsten minor raus. Dazu müssen wir aber nicht auf verschiedenen Branches arbeiten.

• (automatisches) Erzeugen von Tags bei Releases (minor, major, hotfix)

Die Branch-Präfixe haben den Vorteil, dass man die Automatisierung mit den GitHub Actions leicht bewerkstelligen kann. Um momentan automatisiert ein nightly auf der aktuellen feature branch zu erstellen, muss man entweder die aktuelle Versionsnummer tracken (woher ohne auszuchecken?) oder hoffen, dass keine Tippfehler in den branch names sind und man mit git branch -a --sort=-committerdate --no-merged master --list "feature-*" | sort -V | head -n 1" die richtige nächste feature branch bestimmen kann.

Das sollten wir ändern, damit die Nigthlies auf dem feature Branch erstellt werden. Aber Tipfehler kann es doch immer geben, ob es nun "feature-3.1.0" oder "feature/feature-3.1.0" heißt. Oder versteh ich da etwas falsch.

[tolot27]

Sind wirklich so viele Branches nötig? Ich fände es gut, wenn wir dabei bleiben, dass master der Bugfix-Branch ist und es dazu jeweils einen feature Branch für jede Version gibt.

Entschuldige, hier habe ich mich wohl etwas unpräzise ausgedrückt und habe es oben geändert. Die Präfixe betreffen nur lokale branches (im eigenen Fork), die man selbst erstellt und sie dann als PR einreicht. Im main reposit

• intensive Nutzung von git rebase bei den jeweiligen Branches; das Konfliktmanagement ist identisch zu git merge

Was ist der Vorteil von rebase? Ich kenne mich da nicht so genau aus, lokal verwende ich das schon, aber bei upsream Branches habe ich es bisher nie eingesetzt.

Rebase erzeugt keine merge commits und ist das Standardvorgehen bei mehreren Branches.

• automatisches mergen bzw. rebasen von Bugfix-Branches nach "next-hotfix", nachdem die jeweiligen PRs in master gemerged wurden.

warum soll man Bugfix Branches und "next-hotfix", haben? Das ist doch quasi das gleiche. Momentan kommen alle Bugfixes nach master und wenn nötig wird da ein bugfix Release erstellt, dafür ist doch kein extra Branch nötig.

Bugfix branches sind fork-spezifische lokale Branches, die als PR submitted werden. Beim merge dieser PRs könnte automatisch ein hotfix erstellt werden. Das kann man nur automatisieren, wenn es irgendwie erkenntlich ist. Damit nicht bei jedem dieser Merges ein hotfix erzeugt wird, kann man diese in einer next-hotfix branch sammeln.

Ich denke die meisten Änderungen sind minor, wenn dann eine größere Änderung gibt geben wir ein major statt des nächsten minor raus. Dazu müssen wir aber nicht auf verschiedenen Branches arbeiten.

Ja, die meisten neuen neuen features sind next-minor aber nicht notwendigerweise.

Das sollten wir ändern, damit die Nigthlies auf dem feature Branch erstellt werden. Aber Tipfehler kann es doch immer geben, ob es nun "feature-3.1.0" oder "feature/feature-3.1.0" heißt. Oder versteh ich da etwas falsch.

Wenn wir eine Nomenklatur festlegen, sollte sich jeder daran halten. Man kann ja branches auch umbenennen. Eine Branch "feature-3.1.0" (bzw. "next-minor") enthält alle neuen Features, die über PRs gemerged werden. Branches die "feature/feature-3.1.0" heißen, sollte es nicht geben. Vielmehr sollte man seine Branches z. B. "feature/Sollbuchung_Nr" oder von mir aus auch "feature/JohannMaierhofer/Sollbuchung_Nr" nennen, nicht jedoch Versionsnummern da rein codieren, wie es momentan bei JohannMaierhofer:3.1_Sollbuchung_Nr der Fall ist.

[JohannMaierhofer]

Branches die "feature/feature-3.1.0" heißen, sollte es nicht geben. Vielmehr sollte man seine Branches z. B. "feature/Sollbuchung_Nr" oder von mir aus auch "feature/JohannMaierhofer/Sollbuchung_Nr" nennen, nicht jedoch Versionsnummern da rein codieren, wie es momentan bei JohannMaierhofer:3.1_Sollbuchung_Nr der Fall ist.

Warum nicht. Ich mache Bug fixes die müssen in den Main Branch und Features, die müssen dann in den feature-3.1.0 Branch.
Damit ich da nicht durcheinander komme für was ein Branch ist habe ich die Nummer davor gemacht. Das sollte doch kein Problem sein.
Und den PR stelle ich ja auch selbst.

Wenn da etwas automatisch per Script oder Action gemacht werden soll was am Namen abgeleitet wird, dann ok, aber das sehe ich momentan hier nicht. Wenn es einen Grund gibt das anders zu machen schließe ich mich dann natürlich an.

Ich verstehe auch noch nicht ganz wie die Bugfixes automatisch in den Feature Branch kommen sollen. Beim letzten Mal hatte ich den Kommentar auch die Version im plugin.xml auf 3.0.2 zu setzen. Das darf aber doch so nicht in den 3.1.0 Branch.

Das mit dem Rebase verstehe ich auch nicht. Wenn ein PR akzeptiert ist bietet mir Git im Browser an den PR zu mergen. Was müsste ich da machen dass er ein Rebase macht? Und warum eigentlich Rebase, ich dachte, da wird dann meine ganze Kommit Historie mit übertragen. Aber im Main oder dem Feature Branch braucht man die doch garnicht. Da reicht es doch wenn das fertige Feature so wie es ist rein kommt.

[dippeal]

Macht mal bitte einen neuen Thread für die Diskussion "Rules für lokale Entwicklungsumgebung" oder so. Wenn ich das richtig lese werden hier zwei Themen vermischt.
Grundsätzlich hat jeder Entwickler seinen eigenen Stil und ich wäre sehr dafür, dass der Einstieg in die Entwicklung von OJV einfach gehalten wird, damit weitere tolle Leute mit entwickeln.

Den automatischen merge vom master bugfix/patch in den feature branch kann man bestimmt über eine github action umsetzen. Ich habe aktuell nur wenig Zeit. Das Versionslevel in der plugin.xml müsste dabei ignoriert werden, oder einfach beim Erstellen des Release angepasst werden.