where `TAG` is the tag of the last release (e.g. `3.4.0`)
where `TAG` is the tag of the last release (e.g. `3.4.0`)
* __Announce Freeze:__ Announce hard feature freeze. Explain how no further changes to the code,
except for bugfixes and documentation will be accepted. See email examples [here](#example-emails).
* __Header check:__ Check header files by running the command `make headercheck` with with both a minimal and a maximal setup in terms of Dune dependencies. To enable the `headercheck`, turn on
* __Header check:__ Check header files by running the command `make headercheck` with with both a minimal and a maximal setup in terms of Dune dependencies. To enable the `headercheck`, turn on
`headercheck` in the [cmake.opts file](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/cmake.opts)(`DUMUX ENABLE HEADERCHECK = ON`). Look at the error message,
`headercheck` in the [cmake.opts file](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/cmake.opts)(`DUMUX ENABLE HEADERCHECK = ON`). Look at the error message,
and include the correct headers in the failing header.
and include the correct headers in the failing header.
in the DuMu<sup>x</sup> -stable top folder. Use what the script recommends to adapt the lists as needed. If the script is broken, update it.
in the DuMu<sup>x</sup> -stable top folder. Use what the script recommends to adapt the lists as needed. If the script is broken, update it.
* __Run create_cmakelists__: Run the `bin/create_cmakelists.py` script in `dumux/dumux`, in order
* __Run create_cmakelists__: Run the `bin/create_cmakelists.py` script in `dumux/dumux`, in order
to update the cmakelists in the source directory.
to update the cmakelists in the source directory. Be careful to use this script with caution. It only works for standard directories. **DO NOT** blindly commit changes made by the script.
* __Announce Freeze:__ Announce hard feature freeze. Explain how no further changes to the code,
except for bugfixes and documentation will be accepted. See email examples [here](#example-emails).
* __Release Branches: For each DuMu<sup>x</sup> module, create a new branch titled releases/X.Y.__ (e.g., [DuMu<sup>x</sup> 3.7](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/releases/3.7), [DuMu<sup>x</sup>-Lecture 3.7](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-lecture/-/tree/releases/3.7), [DuMu<sup>x</sup>-Course 3.7](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-course/-/tree/releases/3.7)
* __Release Branches: For each DuMu<sup>x</sup> module, create a new branch titled releases/X.Y.__ (e.g., [DuMu<sup>x</sup> 3.7](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/releases/3.7), [DuMu<sup>x</sup>-Lecture 3.7](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-lecture/-/tree/releases/3.7), [DuMu<sup>x</sup>-Course 3.7](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-course/-/tree/releases/3.7)
...
@@ -165,6 +165,7 @@ in the DuMu<sup>x</sup> root directory.
...
@@ -165,6 +165,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
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
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).
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.
* __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.
* __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.
