Notes for managing release (since 2026.04)

The responsibility of the release manager is to

• Create a git Milestone for the release

  The Milestone mark will be used for pull requests which should be backported to the release.

• 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

Of course, the tasks can be delegated. Responsibility can not. :)

All steps have to be repeated for modules opm-common, opm-grid, opm-simulators, and opm-upscaling.

If you find any inaccuracies these Notes for managing release, please update them. Future release manger will thank you.

Creation of the first release candidate

1. Create a new branch for the first release candidate.
   1. The branch naming convention is release/year.month, e.g. release/2026.04. We currently have releases in months 04 and 10.
   2. Open the dune.module change the Version and Label to the release candidate 1, e.g. change 2026.04-pre to 2026.04-rc1.
   3. Add and commit the changes to the dune.module.
   4. 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 release/2026.04/rc1

2. Push the branch into the OPM github remote.

   Push the tag as well.

3. 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.

4. 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.

Users and testers can git checkout release/2026.04/rc1. There is only one branch for the release, the tag creates a snapshot of the code at the moment it was tagged. Tagging is what makes the release candidate.

Backporting: Creation of the second release candidate

For backporting, we will use the script release-scripts/opm-backport-pr.sh from opm-utilities. Make sure that it uses the correct release version.

1. Choose which pull requests should be backported.
2. Test them locally
   1. Cherry pick the chosen pull requests.

      git cherry-pick -m1 hash-of-the-pull-request

   2. Build the modules. If you want to do regression tests, make sure that opm-tests module is in the directory with other modules. (Use opm-tests from the time the release branch was created.)
   3. Run make test.
   • Building again with different parameters (and then testing) is always a good idea.
3. Backport pull requests.
   1. Call the script from the git repository of the module which is getting backports.
   2. The script takes the number of the pull request as an argument and creates a new branch with the changes.

      ./../opm-utilities/release-scripts/opm-backport-pr.sh 6894

   3. Push the branch into your forked repository.

      git push -u fork_name backport-of-pr-6894

   4. Create a pull request against the release branch.
   5. Merge the backporting pull request.
   • Repeat above steps for each pull request which is being backported.

     It is possible to first create several pull requests and then merge them but it is more error prone.

     Make sure the order of merging is the same as in the master branch. The commit history should look like master's, possibly with some omitted (=not backported) pull requests

4. Bump the version in the dune-module
5. Add git tag for the release candidate and push the tag

Other release candidates are created in a similar fashion. The same goes for the final release. The version in the dune.module is simply 2026.04 without and suffix. The tag is release/2026.04/final and, except the version in the dune.module the final version should be identical to some tested release candidate (usually the last one).

Publishing the release on github

1. Go to the github page, click on Tags and choose the final candidate. Click on the Create release from tag button
2. Release notes can be generated automatically. Select the previous final release as the previous tag and use the Generate release notes

   This will automatically fill the Release title and make a list of What's Changed with a link to the Full Changelog.

   If a developer made a first contribution to this module in this release, the automatically generated text will mention them (but it is not 100% reliable).

3. Add Release Highlights to the beginning of the automatically generated list.

   Release notes in the reference manual are a good source of inspiration. Pasting a whole list is fine too.

   Release highlights are usually omitted from opm-upscaling.

Publishing the release announcement on the opm-project website

Posting the announcement is fairly easy. The website is WYSIWYG and previous releases provide enough inspiration. The usual approach is to mention:

1. Installation instructions and what packages are available
2. Links to the releases in github repositories
3. Release highlights
4. Thank you note for contributors and people who helped the with the release (because giving the role of the release manager to a rookie is a tradition)