Notes for managing release (since 2026.04) - Revision history

Michaltoth: /* Publishing the release announcement on the opm-project website */ nitpick

2026-05-21T15:40:45Z

Publishing the release announcement on the opm-project website: nitpick

Michaltoth: Add info for managing the release: website

2026-05-21T15:38:58Z

Add info for managing the release: website

Michaltoth: /* Publishing the release on github */

2026-05-20T14:37:28Z

Publishing the release on github

Michaltoth: /* Publishing the release on github */

2026-05-20T14:35:31Z

Publishing the release on github

Michaltoth at 14:35, 20 May 2026

2026-05-20T14:35:04Z

Michaltoth: /* Backporting: Creation of the second release candidate */

2026-04-20T07:41:02Z

Backporting: Creation of the second release candidate

Michaltoth: /* Backporting: Creation of the second release candidate */

2026-04-20T07:38:47Z

Backporting: Creation of the second release candidate

Michaltoth at 15:00, 16 April 2026

2026-04-16T15:00:35Z

Michaltoth: Detailed manual for the release managers (incomplete).

2026-04-14T15:01:48Z

Detailed manual for the release managers (incomplete).

New page

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.

@@ Line 69: / Line 69: @@
 # Links to the releases in github repositories
 # Release highlights
-# Thank you note for contributors and people who helped the with the release (giving the role of the release manager to a rookie seems popular)
+# 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)

@@ Line 10: / Line 10: @@
 All steps have to be repeated for modules ''opm-common'', ''opm-grid'', ''opm-simulators'', and ''opm-upscaling''.
 ==Creation of the first release candidate==
@@ Line 61: / Line 63: @@
 #: 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.

← Older revision		Revision as of 14:37, 20 May 2026
Line 60:		Line 60:
	# Add ''Release Highlights'' to the beginning of the automatically generated list.		# 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 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.

@@ Line 56: / Line 56: @@
 # Go to the github page, click on ''Tags'' and choose the final candidate. Click on the ''Create release from tag'' button
 # 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.
+#: 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).
+#: 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).
 # 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 notes in the reference manual are a good source of inspiration. Pasting a whole list is fine too.

← Older revision		Revision as of 14:35, 20 May 2026
Line 50:		Line 50:
	# Bump the version in the ''dune-module''		# Bump the version in the ''dune-module''
	# Add git tag for the release candidate and push the tag		# 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==
		+	# Go to the github page, click on ''Tags'' and choose the final candidate. Click on the ''Create release from tag'' button
		+	# 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).
		+	# 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.

@@ Line 34: / Line 34: @@
 ## Cherry pick the chosen pull requests.
 ##: git cherry-pick -m1 ''hash-of-the-pull-request''
-## Build the modules. If you want to do regression tests, make sure that ''opm-tests'' module is in the directory with other modules.
+## 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.)
 ## Run ''make test''.
 #* Building again with different parameters (and then testing) is always a good idea.

← Older revision		Revision as of 07:38, 20 April 2026
Line 48:		Line 48:
	#*: It is possible to first create several pull requests and then merge them but it is more error prone.		#*: 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		#*: 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
		+	# Bump the version in the ''dune-module''
		+	# Add git tag for the release candidate and push the tag

@@ Line 1: / Line 1: @@
 The responsibility of the release manager is to
 * Create release branch and tag release candidates for testing
 * Build binary packages for testing
@@ Line 5: / Line 7: @@
 * 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''
+Of course, the tasks can be delegated. Responsibility can not. :)
 ==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.
+## The branch naming convention is ''release/year.month'', e.g. release/2026.04. 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
+##: git tag release/2026.04/rc1
 # Push the branch into the OPM github remote.
 #: Push the tag as well.
@@ Line 21: / Line 25: @@
 #: 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.