@@ -171,8 +171,7 @@ in the DuMu<sup>x</sup> root directory.
in the dumux repository directory, replacing 3.4.0 by the version of the last release or its commit sha. Alternatively, you may use the graphical overview on [graph](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/network/master), where you
can specify the period of interest using the mouse on the top graph. Be sure to include those who
have contributed to DuMu<sup>x</sup> outside of the main repository (lecture, website, and course).
Keep in mind that squashing commits, can erase work of a person. Think about the script as these are definitely authors. However, there might be people that are not authors according to the script that should be named as authors.
have contributed to DuMu<sup>x</sup> outside of the main repository (lecture, website, and course), if those other repos are also part of the release data set. The script lists the code contributors. These people should definitely be authors of the release dataset. However, there might be people who are not authors according to the script but should be named authors. These are people who have significantly contributed in other ways to the release. For people who have only helped out with small things / testing / reported issues but are not code contributors, there is the option to acknowledge persons in the dataset metadata.
* __Lecture and Course:__ Test or let someone else test DuMu<sup>x</sup>-lecture and DuMu<sup>x</sup>-course. If they build and pass without errors or warnings, mark DuMu<sup>x</sup>-lecture/courses’ current git branch as compatible to the DuMu<sup>x</sup> version your release. This is done by adding a tag (modify the version X.Y): Go to the [gitlab tag section](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-lecture/tags) and click on `+New Tag`. Here, you have to assign the tag name (e.g. 3.5.0) and enter the release branch you tested for compatibility with the current release.
