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.

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