Hallo

Nachdem wir nun bei Version 2.4.1 sind und es mit einer gewissen Wahrscheinlichkeit auch eine 2.4.2 geben wird, sollten wir darüber nachdenken, wie wir die Änderungen für den 2.4-er Zweig von denen für den nächsten Major Release (2.5-er Zweig) trennen. Dazu ein paar Gedanken (die Versionsnummern sind vom aktuellen Stand ausgehend gewählt).

• Die Versionen des 2.4-er Zweigs enthalten nur Fehlerbehebungen. Patches/Commits für diese Fehlerbehebungen sollten in einem Extrabranch gesammelt werden, in dem dann auch die Versionen für diesen Zweig erstellt werden (evtl. mit von diesem abgeleiteten Branches). Sind sie fertig, werden sie mit dem Master-Branch zusammengefüht (merge).
  
• Neue Features kommen in den 2.5-er Zweig. Auch dieser Zweig sollte seinen eigenen Branch auf Github bekommen und Pull-Requests sollten auf diesen Branch zeigen und nicht auf den Master-Branch. Auch hier gibt es den hauptzweig für die Version und bei Bedarf weitere Branches für Features und Versionen, die dann immer wieder in den 2.5-er Zweig eingebaut werden. Auch hier gilt, ist ein Release fertig, wird der aktuelle Stand mit Master zusammengeführt.

Das ist mein erster Gedankengang. Ich habe bisher selbst noch kein Projekt soweit gebracht, dass ich einen Zweig entwickelt und einen anderen noch gepflegt habe (MLF1 vs. MLF2 ist kein passendes Beispiel), geschweige denn, dass ich sowas in einem Versionskontrollsystem gepflegt habe. Wir sollten uns aber darüber verständigen, wie wir das handzuhaben gedenken, bevor wir uns irgendwie verheddern.

Tschö, Auge