Proposal for a post-v19 development and release strategy

[dennisklein]

1. Development happens in the dev branch with PRs against it (unchanged to now)
2. Adopt the Semantic Versioning spec
3. Release:
   a. In an unspecified frequency releases are prepared by forking off a new v<major>.<minor>_patches branch from any appropriate commit (Typically from the dev branch)
   b. Release preparations shall not stall development
   c. A release is finalized by tagging v<major>.<minor>.0 and the creation of a "github release object"
   d. master (maybe rename to main?) shall point to the highest version tag
4. Maintenance:
   a. After release the v<major>.<minor>_patches branch is now the target for maintenance patches and backported fixes as long as the release is actively maintained
   b. Patch release: In an unspecified frequency v<major>.<minor>_patches branches are tagged with an incremented <patch> version
   c. The docs of FairRoot contain a list of actively maintained releases (ideally in a GANTT-chart-like fashion that also documents the planned support period)
   d. Actively maintained releases are tested against all actively maintained FairSoft releases (to be defined)
5. Backports:
   a. Fixes are always backported to all applicable actively maintained releases
   b. Features may be backported as new minor releases if feasible
6. API breakage shall be announced via deprecation and/or via changelog entries
   a. Removal of deprecated API is always a major version bump as a consequence of semver
   b. The wall time between publishing a particular API deprecation and its removal shall be a minimum of six months

---

Open questions from my side:

1. Should/Can we commit to a specified patch release frequency in 4.b? e.g. always tag as soon as possible?
2. Should/Can we commit to a specified procedure that determines the maintenance periods of releases in 4.c?