| ... | ... | @@ -120,10 +120,15 @@ git”) and commit the change. Push the branch: |
|
|
|
__From then on__, changes are still to be made to the master, but the merge commits should be
|
|
|
|
cherrypicked onto the releases/X.Y branch.
|
|
|
|
|
|
|
|
|
|
|
|
* __Install Scripts__: Update all install scripts on the release branch. Create a MR on master to update the installscripts accordingly, but only merge them after the release. We want that the installscript does not default to a unreleased release branch.
|
|
|
|
|
|
|
|
* __dune.module__: Change version from e.g. 3.9-dev to 3.9 on the release branch. Create a MR for master to bump the version. e.g. 3.9-dev to 3.10-dev. Again merge this after the release.
|
|
|
|
|
|
|
|
* __Protect release branches (in GitLab):__ Go to gitlab and make the [release branch](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/protected_branches) protected. Select the release branch to protect. In the ”allowed to merge” column, select maintainers. In the
|
|
|
|
allowed to push column, select no one, then press select. This means that the branch can only be
|
|
|
|
modified via a merge request merged by a maintainer.
|
|
|
|
|
|
|
|
* __CI:__ Reconfigure [the CI](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/pipelines) to test both master and the release branch with the planned configurations. Continue to check the CI for failing automatic tests. In case you need to update or change the generated docker images, this can be done in [this file](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-docker-ci/-/blob/master/.gitlab-ci.yml). The `dumux-docker-ci` repository contains the docker files for the images and its CI builds those images as well as uploads them to the image registry. Additionally, update the [scheduled pipelines](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/pipeline_schedules) to test your and the previous release branch as well as the master branch (keep that). If the DuMu<sup>x</sup> pipelines should be run with other docker images, adapt [this file](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/.gitlab-ci.yml).
|
|
|
|
|
|
|
|
* __Local Testing:__
|
| ... | ... | @@ -172,7 +177,6 @@ Keep in mind that squashing commits, can erase work of a person. Think about the |
|
|
|
* __Website:__
|
|
|
|
-Update the make handbook script. Look at commit a87e55d2793edeb8fdfe0c1115520d509f3d6775 for an example.
|
|
|
|
|
|
|
|
- Link the proper handbook version.
|
|
|
|
- Link the proper doxygen version.
|
|
|
|
- Update any changes to the installation guidelines.
|
|
|
|
|
| ... | ... | @@ -190,12 +194,14 @@ See email examples [here](#example-emails). |
|
|
|
|
|
|
|
## Releasing DuMu<sup>x</sup>
|
|
|
|
|
|
|
|
__Important__ These steps are normally done together with Bernd. Make sure to schedule the time properly.
|
|
|
|
__Important__: If possible start early in the morning with these tasks. You can prepare everything on your own, however do the final step together with Bernd.
|
|
|
|
For instance you can create the release entry,tags and badges but submitting darus for review and should be done with Bernd.
|
|
|
|
|
|
|
|
* __Protect release branches (in GitLab):__ Go to gitlab and make the [release branch](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/protected_branches) protected. Select the release branch to protect. In the ”allowed to merge” column, select maintainers. In the
|
|
|
|
allowed to push column, select no one, then press select. This means that the branch can only be
|
|
|
|
modified via a merge request merged by a maintainer.
|
|
|
|
*__DaRUS permissions__: Ask Bernd for permissions in DaRUS.
|
|
|
|
|
|
|
|
*__Sofwareheritage__: Make sure that your release branch is available at [softwareheritage](https://archive.softwareheritage.org/browse/snapshot/50fb10d5d33803233d6475cf1fab33b088c8a143/releases/?origin_url=https://github.com/dumux/dumux)
|
|
|
|
- If it is not, click on `save again` on the [code page of softwareheritage](https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://github.com/dumux/dumux&snapshot=50fb10d5d33803233d6475cf1fab33b088c8a143)
|
|
|
|
- Keep this window open the whole time, you will need it.
|
|
|
|
|
|
|
|
* __Create new tags:__
|
|
|
|
- Go to the [gitlab tag section](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/tags)
|
| ... | ... | @@ -207,8 +213,6 @@ of the last commit for the current release. |
|
|
|
* __DaRUS citation:__ To cite the release, we create a doi using [DaRUS](https://darus.uni-stuttgart.de/dataset.xhtml?persistentId=doi:10.18419/darus-3405), and a tarball of the software.
|
|
|
|
Bernd has the account details and can help you with this. It would be helpful to prepare a list of those
|
|
|
|
who should be included in the citation as authors beforehand. Some helpful tips:
|
|
|
|
- Make sure that your release branch is available at [softwareheritage](https://archive.softwareheritage.org/browse/snapshot/50fb10d5d33803233d6475cf1fab33b088c8a143/releases/?origin_url=https://github.com/dumux/dumux)
|
|
|
|
- If it is not, click on `save again` on the [code page of softwareheritage](https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://github.com/dumux/dumux&snapshot=50fb10d5d33803233d6475cf1fab33b088c8a143)
|
|
|
|
- Upload a tar.gz file of the DuMux release to DaRUS
|
|
|
|
- In general, follow the structure of the [DaRUS entry for release e.g. 3.7](https://darus.uni-stuttgart.de/dataset.xhtml?persistentId=doi:10.18419/darus-3405)
|
|
|
|
- text formatting in DaRUS is done via html syntax
|
| ... | ... | |
