Implement minor/major/main(release) branch scheme according to SemVer

[jmark]

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.

[jmark]

I agree. However, I would wait till JH returns and also when t8code matured a little bit further.

[holke]

I think this introduces way too much overhead and will result in a system that we will never maintain properly.

Keep in mind, that we do not need to make a new release for every PR into main.
Releases are just specific points in the history of main, which we decided are now "changed enough" to get a proper label.