docs: Start on the Release Process

Be more transparent about our release process.

Co-Authored: @karabowi
Co-Authored: @dennisklein

Author: ChristianTackeGSI

CONTRIBUTING.md

@@ -12,7 +12,7 @@ Create a [Github Pull Request](https://github.com/FairRootGroup/FairRoot/compare
    branch and base your PR against it.
    * In rare cases (e.g. backports, some hotfixes) base against the appropriate
      branch.
-2. If you are a first time contributor, add a separate commit in your PR which
+2. If you are a first-time contributor, add a separate commit in your PR which
    adds your name to the [`CONTRIBUTORS`](CONTRIBUTORS) file.
 3. Follow our [Coding Guidelines](#coding-guidelines).
 4. Expect that a reviewer will ask you for restructuring your commits! This
@@ -128,3 +128,83 @@ for (auto const& listEntry : *list) { /*...*/ } // avoid
 for (auto const& aVol : *volList) { /*...*/ }   // acceptable
 for (auto const& volume : *volumes) { /*...*/ } // ✓ prefer
 ```
+
+
+# Creating a new Release
+
+(This is basically for the release manager.
+So that we don't forget anything.)
+
+## Control the status
+
+* Take a look at the
+  [Milestone](https://github.com/FairRootGroup/FairRoot/milestones)
+  for the release
+
+  Consider moving still open items to another milestone
+
+## Check the CI Coverage
+
+* Remind/ask myself what platforms the release is targeting (I roughly
+  target the last two years of releases for ubuntu/fedora, debian
+  stable/oldstable + anything older, if relevant in GSI still)
+* Then I compare what is currently tested via CI and decide whether it
+  needs an updates, e.g.
+   * regenerate/update existing images (cover new FairSoft releases? get
+     latest os updates to test closer to what a user may use)
+   * add new images (new os releases? which ship new compiler major versions
+     perhaps)
+   * remove old images
+   * For macs it involves similar steps, updating homebrew, perhaps the os
+     or the command line tools
+* Fix issues resulting from previous step
+
+## Create a commit
+
+On the `v{x.y}_patches` branch with comment `Bump v{x.y.z}`:
+
+* Double check that the version number on the `project`
+  line in [CMakeLists.txt](CMakeLists.txt) is correct
+
+* Apply some final editorial changes to the
+  [CHANGELOG](CHANGELOG.md) for the upcoming release
+  * Remove the `(UNRELEASED)` tag on the header
+  * Add the correct date
+  * Go over the list and re-order things/etc (classical
+    editorial changes)
+
+* Apply editorial changes to [README](README.md)
+
+* (Soon)
+  * Check that `codemeta.json` and friends have been
+    updated.
+  * Get a zenodo entry ready
+
+## Push the patch to the repository:
+
+* ```sh
+  git push origin v{x.y}_patches
+  ```
+
+* Check the CI so that all checks pass for the branch
+
+## Create, control and push the new tag to the repository:
+
+```sh
+git tag v{x.y.z} -a -s
+git show v{x.y.z}
+git push origin v{x.y.z}
+```
+
+## Create a new release on GitHub.
+
+## In certain cases the tag should be merged onto master:
+
+```sh
+git checkout master
+git merge origin/v{x.y}_patches
+git push mainrepo origin
+```
+
+The message, when prompted, should be `Merge v{x.y.z}`.
+The merge and push should not be forced.