Releases als Milestones zu Issues und Pull Requests zuordnen

[datengraben]

Ein Vorschlag von mir im Titel der Diskussion oben.

Vorteile:

• Daraus kann man Release (bzw. Changelog) Notes generieren lassen.
• Bei geschlossenen Issues oder gemerged Pull Requests ist transparent in welchem Release sie stecken. So muss ich selber manuell schauen zwischen welchen Tags die Commits liegen.
• Alle umgesetzten Features können aus den geschlossenen Issues oder geschlossenen Pull Requests nachvollzogen werden

Nachteile:

• Mehraufwand durch Abstimmung untereinander und manueller Zuordnung

Was denkt ihr darüber?

EDIT:

Ich habe das mal testweise für einige Issue für das nächste Release 2.7.4 gemacht
https://github.com/wielebenwir/commonsbooking/milestone/24

[hansmorb]

Danke dir, nächster Release ist 2.8, weil doch einige neue Sachen im Master sind. Das wird aus dem Master abgezweigt in Release/2.8 wenn die Backendbuchung fertig ist. Dann wird auf dem Branch getestet. Ich hatte schon den Milestone "Nächster Release" angelegt weil ich nicht wusste wie man das dann pro Release macht, gibt es da ne Anleitung dazu?

[datengraben]

Das wäre schon der Milestone 2.8.0 https://github.com/wielebenwir/commonsbooking/milestone/25

[datengraben]

Mh der hier sieht besser aus, wird auch noch maintained.
https://github.com/softprops/action-gh-release

[datengraben]

Damit kann man sogar direkt das fertig gepackte Plugin auf Wordpress-Plugins.org hochladen https://github.com/10up/action-wordpress-plugin-deploy

[hansmorb]

@datengraben Hmm, wir können darüber ja auch nochmal abstimmen aber mein Gefühl sagt mir, dass es den Aufwand nicht wert ist da eine automatisierte Release Pipeline zu schaffen, da wir ja sowieso relativ selten Updates veröffentlichen.

[datengraben]

@datengraben Hmm, wir können darüber ja auch nochmal abstimmen aber mein Gefühl sagt mir, dass es den Aufwand nicht wert ist da eine automatisierte Release Pipeline zu schaffen, da wir ja sowieso relativ selten Updates veröffentlichen.

Stimmt, gerne abstimmen. Auf der anderen Seite können wir dann schneller reagieren, wie z.B. bei dem Hotfix kurz nach dem Release.