Implement minor/major/main(release) branch scheme according to SemVer #358
Description
Sandro:
Ich weiß, dass ich die Abschaffung des Develop Branches angestoßen habe, aber seitdem wir uns ans Semantic Versioning halten, wäre die Einführung eines oder besser zweier Branches ganz sinnvoll.
Aktuell pushen wir ja alles in den main und machen irgendwann einen Release, wenn es uns sinnvoll erscheint. Das wird aber meines Erachtens nach fast immer in einem major Release enden, da das so gefordert wird, sobald es auch nur einen PR mit einer Änderung am bestehenden Interface gibt. Eine solche Änderung wäre zum Beispiel schon das Verschieben von t8_cmesh_set_tree_vertices, was ich ja schon im anderen Channel angesprochen habe.
Deswegen habe ich folgenden Vorschlag:
Neben dem main Branch machen wir zwei weitere Branches major und minor auf, die immer up to date mit main sein sollten. Wenn wir jetzt eine PR stellen, stellen wir die in main, wenn er im Sinne von semver nur Patches enthält.
Wenn die Einführung des Features einen minor Release erfordert, stellen wir die PR in minor und wenn ein major Release erforderlich ist in major.
Und dann können wir die Branches immer bei einem major oder minor Release in main mergen, haben die Features aber schon vorher in irgendwelchen Branches zusammengefasst und somit nutzbar.
So landen wir nicht innerhalb eines Jahres bei t8code Version 15.0.0 und wir können Updates besser bundeln.