Difference between revisions of "Creating a Release"

From Mpich
Jump to: navigation, search
Line 13: Line 13:
 
Check all tests.  This includes  
 
Check all tests.  This includes  
 
# The four major test suites (MPICH, C++, Intel, MPICH2)
 
# The four major test suites (MPICH, C++, Intel, MPICH2)
# The special tests (See [[http://wiki.mcs.anl.gov/mpich2/index.php/Testing_MPICH2#Running_the_Special_Tests]] ); these are important for testing that various options and compiler choices work
+
# The special tests (See [[http://wiki.mcs.anl.gov/mpich2/index.php/Testing_MPICH#Running_the_Special_Tests]] ); these are important for testing that various options and compiler choices work
 
# The "random" tests in the nightly test should not indicate any problems; these are used to test correct handling of the configure options
 
# The "random" tests in the nightly test should not indicate any problems; these are used to test correct handling of the configure options
 
# Ensure that the Debugger interface works; <code>(cd src/mpi/debugger ; make tvtest)</code> can be used as a start; a check with <code>totalview</code> should also be performed
 
# Ensure that the Debugger interface works; <code>(cd src/mpi/debugger ; make tvtest)</code> can be used as a start; a check with <code>totalview</code> should also be performed
Line 29: Line 29:
  
 
* A branch is only created once for a complete release cycle, i.e., <code>1.0.7rc1</code>, <code>1.0.7rc2</code>, <code>1.0.7</code>, <code>1.0.7p1</code>, etc., will have just one branch. At what point a release branch is to be created is not decided yet (e.g., alpha releases, beta releases, RCs, full release), but we currently do that at the time of the RC release. This essentially means an svn-copy of the trunk to the branches/release directory.
 
* A branch is only created once for a complete release cycle, i.e., <code>1.0.7rc1</code>, <code>1.0.7rc2</code>, <code>1.0.7</code>, <code>1.0.7p1</code>, etc., will have just one branch. At what point a release branch is to be created is not decided yet (e.g., alpha releases, beta releases, RCs, full release), but we currently do that at the time of the RC release. This essentially means an svn-copy of the trunk to the branches/release directory.
* If this is the first RC for this release cycle, create a branch. Branches are named as <code>mpich2-X.Z.Y</code>, where <code>X</code>, <code>Y</code>, <code>Z</code> are the major, minor and revision version numbers.
+
* If this is the first RC for this release cycle, create a branch. Branches are named as <code>mpich-X.Z.Y</code>, where <code>X</code>, <code>Y</code>, <code>Z</code> are the major, minor and revision version numbers.
 
* If this is not the first RC, merge all required changes from the trunk to the release branch.
 
* If this is not the first RC, merge all required changes from the trunk to the release branch.
* A tag is created for every release from the branch. Tag is essentially an svn-copy of the branch to the tags/release directory. Tags are named as <code>mpich2-X.Y.Z[ext]</code>, where <code>[ext]</code> is <code>a1</code>/<code>a2</code>/.. (for alpha releases), <code>rc1</code>/<code>rc2</code>/.. (for RC releases), etc.
+
* A tag is created for every release from the branch. Tag is essentially an svn-copy of the branch to the tags/release directory. Tags are named as <code>mpich-X.Y.Z[ext]</code>, where <code>[ext]</code> is <code>a1</code>/<code>a2</code>/.. (for alpha releases), <code>rc1</code>/<code>rc2</code>/.. (for RC releases), etc.
  
 
=== Create a final tarball for the release ===
 
=== Create a final tarball for the release ===
Line 38: Line 38:
 
   ./release.pl --source=[path_to_tag_dir] --psource=[path_to_first_release_in_major_series] --version=[version]
 
   ./release.pl --source=[path_to_tag_dir] --psource=[path_to_first_release_in_major_series] --version=[version]
 
* Create tarball for hydra
 
* Create tarball for hydra
** Extract MPICH2 taball
+
** Extract MPICH taball
** Create tarball of hydra directory.  Use the same version number as MPICH2.
+
** Create tarball of hydra directory.  Use the same version number as MPICH.
  
=== Update MPICH2 website ===
+
=== Update MPICH website ===
  
 
* Update staging area and create directory for tarballs
 
* Update staging area and create directory for tarballs
Line 47: Line 47:
 
svn up # or svn co https://svn.mcs.anl.gov/repos/mpi-private/www
 
svn up # or svn co https://svn.mcs.anl.gov/repos/mpi-private/www
 
mkdir downloads/tarballs/[version]</pre>
 
mkdir downloads/tarballs/[version]</pre>
* Copy MPICH2 and Hydra tarballs into new directory
+
* Copy MPICH and Hydra tarballs into new directory
 
* Add tarballs to svn
 
* Add tarballs to svn
 
   svn add downloads/tarballs/[version]
 
   svn add downloads/tarballs/[version]
Line 58: Line 58:
 
** For full release update documentation as well
 
** For full release update documentation as well
 
*** <code>documentation/docs.php</code>
 
*** <code>documentation/docs.php</code>
*** Copy README.txt, installguide.pdf, userguide.pdf and windevguide.pdf into <code>documentation/files</code> with <code>mpich2-[version]-</code> prefix
+
*** Copy README.txt, installguide.pdf, userguide.pdf and windevguide.pdf into <code>documentation/files</code> with <code>mpich-[version]-</code> prefix
 
*** Add to svn
 
*** Add to svn
   svn add documentation/files/mpich2-[version]-*
+
   svn add documentation/files/mpich-[version]-*
 
* Test staging website
 
* Test staging website
 
<pre>http://www.mcs.anl.gov/research/projects/mpich2staging/${USER}/</pre>
 
<pre>http://www.mcs.anl.gov/research/projects/mpich2staging/${USER}/</pre>
Line 73: Line 73:
 
* If there are any pending tickets, move them to the next release.
 
* If there are any pending tickets, move them to the next release.
  
=== Send out the release announcement to mpich2-[email protected]mcs.anl.gov and party! Yay! ===
+
=== Send out the release announcement to [email protected]mpich.org and party! Yay! ===
  
 
The older version of these release instructions can be found here: http://www.mcs.anl.gov/research/projects/mpich2/olddeveloper/release.htm
 
The older version of these release instructions can be found here: http://www.mcs.anl.gov/research/projects/mpich2/olddeveloper/release.htm
  
 
<!-- vim: set ft=wikipedia : -->
 
<!-- vim: set ft=wikipedia : -->

Revision as of 16:03, 10 November 2012


Creating the release has the following steps:

Check the Release Status

See the page https://trac.mcs.anl.gov/projects/mpich2/roadmap for the relevant release to ensure that all pending bugs have been fixed.

Ensure that all testing has been performed

This includes both the results of the nightly tests and the special tests that are used to check that common configuration options continue to work and that the coding standards have been followed.

TODO: There was a comprehensive checklist of the prerequisites for a release. That needs to be placed here. Recent releases have not checked this list. What follows is a partial list

Check all tests. This includes

  1. The four major test suites (MPICH, C++, Intel, MPICH2)
  2. The special tests (See [[1]] ); these are important for testing that various options and compiler choices work
  3. The "random" tests in the nightly test should not indicate any problems; these are used to test correct handling of the configure options
  4. Ensure that the Debugger interface works; (cd src/mpi/debugger ; make tvtest) can be used as a start; a check with totalview should also be performed
  5. Ensure that there are no performance artifacts, both for point-to-point and collective operations.
  6. Check the MPE build, including Jumpshot. Ensure Jumpshot can read and display slog files.

Update all necessary files and commit them to the trunk

  • Update the version number in maint/version.m4.
  • Update the CHANGES file. You can find the commits that went in by going through the svn log information.
  • Update the RELEASE_NOTES file. This requires input from everyone, and generally requires asking each person (in person) if the current restrictions still apply, and if any new ones should be added.
  • Update the README if necessary.

Create a release branch and tag

  • A branch is only created once for a complete release cycle, i.e., 1.0.7rc1, 1.0.7rc2, 1.0.7, 1.0.7p1, etc., will have just one branch. At what point a release branch is to be created is not decided yet (e.g., alpha releases, beta releases, RCs, full release), but we currently do that at the time of the RC release. This essentially means an svn-copy of the trunk to the branches/release directory.
  • If this is the first RC for this release cycle, create a branch. Branches are named as mpich-X.Z.Y, where X, Y, Z are the major, minor and revision version numbers.
  • If this is not the first RC, merge all required changes from the trunk to the release branch.
  • A tag is created for every release from the branch. Tag is essentially an svn-copy of the branch to the tags/release directory. Tags are named as mpich-X.Y.Z[ext], where [ext] is a1/a2/.. (for alpha releases), rc1/rc2/.. (for RC releases), etc.

Create a final tarball for the release

  • Get the release.pl script in maint from the trunk and run it as
 ./release.pl --source=[path_to_tag_dir] --psource=[path_to_first_release_in_major_series] --version=[version]
  • Create tarball for hydra
    • Extract MPICH taball
    • Create tarball of hydra directory. Use the same version number as MPICH.

Update MPICH website

  • Update staging area and create directory for tarballs
cd /mcs/web/research/projects/mpich2staging/${USER}
svn up # or svn co https://svn.mcs.anl.gov/repos/mpi-private/www
mkdir downloads/tarballs/[version]
  • Copy MPICH and Hydra tarballs into new directory
  • Add tarballs to svn
 svn add downloads/tarballs/[version]
  • Update files to reflect new release:
    • downloads/downloads.php
      • For preview release add release version to pversion variable.
      • For full releases leave pversion blank and update version
    • index.php
    • about/news.php
    • For full release update documentation as well
      • documentation/docs.php
      • Copy README.txt, installguide.pdf, userguide.pdf and windevguide.pdf into documentation/files with mpich-[version]- prefix
      • Add to svn
 svn add documentation/files/mpich-[version]-*
  • Test staging website
http://www.mcs.anl.gov/research/projects/mpich2staging/${USER}/
  • If all looks OK, commit
 svn commit
  • Update live website
 cd /mcs/web/research/projects/mpich2
 ./update   # sets umask correctly and then runs "svn update"

Mark the milestone complete on TRAC

  • If there are any pending tickets, move them to the next release.

Send out the release announcement to [email protected] and party! Yay!

The older version of these release instructions can be found here: http://www.mcs.anl.gov/research/projects/mpich2/olddeveloper/release.htm