v4.1.5 release checklist

[bwbarrett]

NOTE: The Open MPI v4.1.x branch was created after v4.0.5. Hence, for some of the git log ... commands, the last_release_tag should probably be v4.0.5.

Build the Release

• [ ] Verify the major,minor,release,greek version numbers in VERSION
• [ ] Update the c:r:a shared library version number(s) in VERSION per the GNU Libtool shared library version number rules
  • NOTE: It may be helpful to use a command like git checkout BRANCH; git pull --rebase; git log --stat --topo-order --decorate TAG_FROM_PREVIOUS_RELEASE..HEAD to examine the Git logs and see what has changed.
  • [ ] IF RELEVANT: If this is a new backwards-compatible release on a single branch (i.e., this is vx.y.z where z>1), you probably want to examine git log --stat --no-merges last_release_tag..this_branch_name to see what source code files have changed (which directly impacts how to increment the c:r:a values).
  • [ ] IF RELEVANT: If this is a new release series (e.g., vx.y.0), set r to 0 and increase c values by 10 compared to the first release in the prior series (i.e., vx.(y-1).0 or v(x-1).0.0, as relevant).
  • [ ] IF RELEVANT: If this is a new backwards-compatible release series (i.e., vx.y.0, where y>1), seta values to 10 so that the shared libraries will be ABI compatible with the prior release series.
  • [ ] IF RELEVANT: If this is a new backwards-INcompatible release series (i.e., vx.0.0), set a values to 0 so that there is no possibility of users accidentally mixing shared library versions.
• [ ] Update all documentation files (especially including dates and version numbers), including:
  • [ ] README: all relevant updates, build options, etc. Be sure to update the date near the top of the file.
  • [ ] NEWS: List all user-noticeable changes. Similar to setting shared library versions (above):
    • Pro tip: if this is a new release on a single branch (i.e., this is vx.y.z where z>1), you probably want to examine git log --stat --no-merges last_release_tag..this_branch_name to see what has changed.
    • Pro tip: if this is a new release series (i.e., this is vx.y.0 where y>1, or this is vx.0.0), you will need to be more creative in examining the git logs because this release is on a different branch than the prior release (vx.(y-1).z). Hence, git log ... last_release_tag..this_branch_name will not necessarily give you need. You may need to merge what has changed on your branch with what has changed on the prior release branch, depending on when the prior release branched from this branch. Read the SPECIFYING RANGES section gitrevisions(7) for more details.
  • [ ] LICENSE: Update the years in the copyright notices

Publish pre-releases

• [ ] Create a tag for the pre-release, matching the version being released (ie, git tag -a v3.0.1rc1 <HASH>). Verify <HASH> was a nightly tarball hash and that the MTT results look good. Push the tag for a release.
• [ ] Run the Tarball Builder Job on Jenkins to build the pre-release tarball.
• [ ] Update the web site to show the release: edit software/ompi/vCURRENT_RELEASE software/ompi/version.inc
  • [ ] After merging the PR on ompi-www, wait for it to show up on the web site (might take up to 30 minutes?)
• [ ] Send an email to the [email protected] and [email protected] mailing lists announcing the pre-release

Make the release tarball

• [ ] Create a tag for the release, matching the version being released (ie, git tag -a v3.0.1 <HASH>). Verify <HASH> was a nightly tarball hash and that the MTT results look good. Push the tag for a release.
• [ ] Run the Tarball Builder Job on Jenkins to build the tag as a release build.

Publish the release

• DO NOT DO A FINAL RELEASE if you are too close to Supercomputing and/or Christmas. If you release during these time periods, there can be a ~2 week delay while the Open MPI developer community is not paying attention to their email (and will not be able to respond to the inevitable post-release user emails).
• [ ] Update the web site to show the release
  • If Z is 0 (i.e., this is the first release in a series):
    • [ ] cp -r software/ompi/vCURRENT_RELEASE software/ompi/vRELEASE (where RELEASE is for the new release X.Y and CURRENT_RELEASE is the X.Y of the current release)
    • [ ] Edit each file in the new directory to update for the new release
      • [ ] Edit timeline-graph.php to indicate relevant dates, such as branching
    • [ ] Update version.inc to remove the "existing" versions from the previous release
    • [ ] Edit software/ompi/nav.inc and make this release series be the current stable release; shift other release series down as appropriate
    • [ ] Edit nightly/index.php to make this release series be the current stable release; shift other release series snapshot tarballs down as appropriate
    • [ ] Edit software/ompi/current/version.inc to set the new release series as the current software release.
    • [ ] Edit software/ompi/major-changes.php to list any incompatibilities from prior releases.
  • [ ] Add the new version in version.inc
  • [ ] Update timeline-graph.php (in the same directory as version.inc) to add a date stamp to the timeline graph for the release of this version (i.e., call milestone() like it is for the other releases)
  • [ ] Update the top-level index.php with a news bullet about this release. It is likely possible to guess the correct URL that will be used to web archive the announcement mail sent to [email protected]
• [ ] Publish the newest version of the man pages
  • [ ] Download the man pages tarball from the Jenkins build (there will be a link in the description of the build on Jenkins, note that the URL is only good for 30 days from the build)
  • [ ] Untar the tarball in the top level of the ompi-www directory
  • [ ] git add doc/vRELEASE
  • [ ] If this is a new release series:
    • [ ] Update doc/index.php to list the new directory and git add it
    • [ ] Remove and re-create the current sym link to point to the correct directory and git add it
• [ ] git commit -s to commit all the web site changes
• [ ] git push all web site changes
  • [ ] Verify the live web site to ensure all changes are both present and correct (updates happen every 15 minutes or so...)
• [ ] Close the relevant Github milestone in open-mpi/ompi
• [ ] Send an email to the [email protected] mailing list announcing the release
• [ ] Verify that the URL used to link to the release announcement (to [email protected]) is correct on the front Open MPI web page.

Prep for next release in series

• [ ] Ensure that new Github milestones exist in GitHub for the next release
• [ ] Re-target (change milestone) all still-open issues for the new release to the next major or minor release of Open MPI as appropriate
• [ ] Update the Open MPI version number in VERSION to <NEXT_VERSION> and set greek to a1
• [ ] Open a duplicate of this issue for the next release in this series.