View source for Notes for managing release (since 2026.04)

The responsibility of the release manager is to
* Create release branch and tag release candidates for testing
* Build binary packages for testing
* Backport bugfixes and other high-priority pull requests
* Update the version of the modules

Note that all steps have to be repeated for modules ''opm-common'', ''opm-grid'', ''opm-simulators'', and ''opm-upscaling''

==Creation of the first release candidate==
# Create a new branch for the first release candidate.
## The branch naming convention is ''year.month'', e.g. 2026.04, and we currently have releases in months 04 and 10.
## Open the ''dune.module'' change the Version and Label to the release candidate 1, e.g. change 2026.04-pre to 2026.04-rc1.
## Add and commit the changes to the ''dune.module''.
## Give the branch the tag of the release candidate: ''branch_name''/rc1. Make sure the tag is placed after the version change was committed. If it was placed before, delete the tag and create it again after the commit.
##: git tag 2026.04/rc1
# Push the branch into the OPM github remote.
#: Push the tag as well.
# Update the version of the master branch.
#: This is done via a normal pull request from your forked repository. Update the Version and Label in ''dune.module'', e.g. from 2026.04-pre to 2026.10-pre. Note that master is always ahead of release.
# Update the release version in the shell scripts in ''opm-utilities''.
#: Relevant files are ''release-scripts/opm-backport-pr.sh'' and '' release-scripts/opm-release-install-test.sh''.
#: This is done via a normal pull request like the version-updating of the master branch.