Notes for managing release (since 2026.04)

From opm
Jump to navigation Jump to search

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

  1. Create a new branch for the first release candidate.
    1. The branch naming convention is year.month, e.g. 2026.04, and 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 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.
Retrieved from "http://wiki.opm-project.org/index.php?title=Notes_for_managing_release_(since_2026.04)&oldid=1913"