v5.0.1 checklist

[wenduwan]

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»
• Create a tag for the release, matching the version being released (ie, git tag -a v3.0.1 <HASH>, or git tag -a v4.0.0rc1 <HASH>). Verify 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 (or release candidate)

• 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 and each release candidate
  • 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
• For the final release:
  • If Z is 0, then 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.
  • Add the new version in version.inc
  • ** Where to mail: **
    • IF release candidate:**
    • ** if rc1 ** send to: [email protected], [email protected], and [email protected].
    • ** if later rc, but NOT release **, just send to [email protected].
  • IF NOT release candidate: 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)
  • IF NOT release candidate: 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: Check with Jeff on instructions for RTD-based releases

[wenduwan]

Bump versions #12177

[wenduwan]

Update website open-mpi/ompi-www#483

[wenduwan]

Bump versions again after release #12188

[wenduwan]

Announcement is alive https://www.mail-archive.com/[email protected]/msg00166.html

[wenduwan]

Update website main page open-mpi/ompi-www#484