Skip to content

v2.0.2 release checklist #2579

Closed
Closed
@jsquyres

Description

@jsquyres

Make a perfect tarball

  • Update the major,minor,release,greek version numbers in VERSION
  • Update the shared library version number(s) in VERSION per the GNU Libtool shared library version number rules (pro tip: you probably want to use git log --stat --no-merges last_release_tag..HEAD)
  • 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.
    • AUTHORS: via contrib/dist/make-authors.pl (and commit the result)
    • NEWS: List all user-noticable changes
    • LICENSE: Update the years in the copyright notices
    • ...any other doc files that may not be included in this list
  • Make final openmpi-x.y.z.tar.gz and openmpi-x.y.z.bz2 tarballs using the make_dist_tarball script in contrib/dist

Ensure that the tarball actually works

  • Ensure openmpi make distcheck passes
  • Build and install Open MPI (from a tarball)
    • Check that the version number and release date is correct in the installed man pages
  • Build and run the examples in the tarball
    • MPI / C bindings
    • MPI / C++ bindings
    • MPI / All three Fortran bindings
    • OSHMEM / C bindings (don't run if not using ikrit)
    • OSHMEM / Fortran bindings (don't run if not using ikrit)
  • Build and install the IBM tests from the ompi-tests repo
    • Ensure the tests pass with at least 1 or 2 different MPI transports
  • With a prior release tarball from the same release series:
    • Build and install Open MPI
    • Build all the examples in the tarball (against the prior OMPI release)
    • Build the IBM tests from the ompi-tests repo (against the prior OMPI release)
    • rm -rf the installation of the prior release
    • Set LD_LIBRARY_PATH to point to the installation of the new Open MPI
    • Run examples, make sure they still work
    • Run IBM tests, make sure they still work

Test packaging

  • Ensure that building an Open MPI source RPM works on a RHEL system
  • Ensure that building the Open MPI binary RPM works on a RHEL system (note had to do hacking on buildrpm.sh script and it doesn't report correct information about where rpms are installed, at least not on my RHEL7.2 system running as root)
  • Install both RPMs on an RHEL system
  • Test building and running the IBM tests against the RPM-installed Open MPI
  • Test building a MPI-based program with the output from pkg-config with the RPM-installed openmpi.pc
  • Test that uninstall of the rpm works

Do the release

  • git tag -a vX.Y.Z on the appropriate Open MPI release branch
  • git push --tags --dry-run to the ompi repo. Remove --dry-run when you're convinced it is correct.
  • Publish the tarballs on the Open MPI web site
    • If Z is 0 (i.e., this is the first release in a series):
      • cp -r software/ompi/v2.0 software/ompi/vRELEASE (where RELEASE is X.Y)
      • Edit each file in the new directory to update for the new release
      • Remove all prior tarballs from the downloads subdirectory
    • Add the tarball + SRPM files to the appropriate ompi-www directory (e.g., software/ompi/v2.0/downloads/).
    • Update the md5sums.txt and sha1sums.txt file in that directory (e.g., md5sum openmpi* > md5sums.txt)
    • Update the latest_snapshot.txt file in that directory
    • Update version.inc in one directory up
    • Update index.php (in the same directory as version.inc) and add the prior release to the $versions[] array so that it shows up in the older releases list
    • 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 announce@lists.open-mpi.org
    • Git commit and push all these changes
  • Publish the newest version of the man pages
    • Download and un-tar a new Open MPI release tarball (no need to config/rebuild/install it)
    • Get a git clone of the Open MPI repo, checkout the branch that you are releasing
    • Check out the vA.B.C release tag that you are releasing
    • In the top-level directory of the expanded tarball, run
      contrib/dist/make-html-man-pages.pl from the git clone checked out at the vA.B.C release tag (this file is not in the release tarball)
      • This will take a little time because it will configure and build Open MPI, and then convert all the man pages to HTML.
      • You can ignore warnings about the "" macro not being recognized
    • In the ompi-www repo:
      • git rm -rf doc/vRELEASE and commit
      • mkdir doc/vRELEASE
      • cp -rp YOUR_BUILD_TREE/man-page-generator/php/* .
      • git add doc/vRELEASE
      • If this is a new release series update doc/index.php to list the new directory and git add it
      • git commit -s
    • Git push all web site changes
    • Verify the live web site to ensure all changes are both present and correct
  • Close the relevant Github milestone in open-mpi/ompi
  • Re-target all still-open v2.0.2 issues for v2.0.3 or v2.1.0, as appropriate
  • Ensure that new Github milestones exist in open-mpi/ompi for the next release
  • Update the Open MPI version number in VERSION to <NEXT_VERSION> and get greek to a1
  • Send an email to the announce@lists.open-mpi.org mailing list announcing the release
  • Verify that the URL used to link to the release announcement (to announce@open-mpi.org) is correct on the front Open MPI web page.

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions