Difference between revisions of "Creating a Release"

From Mpich
Jump to: navigation, search
(Send out the release announcement to mpich2-announce@mcs.anl.gov and party! Yay!)
Line 26: Line 26:
  
 
* Update the news and downloads sections on the main page as well as on their detailed description pages.
 
* Update the news and downloads sections on the main page as well as on their detailed description pages.
 +
* Update the user, install and windev guides.
 +
* Update the documentation pages to point to the right version.
  
* Update the user, install and windev guides.
+
=== Mark the milestone complete on TRAC ===
  
* Update the documentation pages to point to the right version.
+
* If there are any pending tickets, move them to the next release.
  
 
=== Send out the release announcement to mpich2-announce@mcs.anl.gov and party! Yay! ===
 
=== Send out the release announcement to mpich2-announce@mcs.anl.gov and party! Yay! ===

Revision as of 16:48, 22 July 2009


Creating the release has the following steps:

Update all necessary files and commit them to the trunk

  • Update the version number in maint/Version.
  • 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 mpich2-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 mpich2-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] [version]"
  • Commit the tarballs to the MPICH2 website SVN copy (www/downloads/tarballs) and update the downloads and main pages with the release information.
  • Update the SVN working copy for the main MPICH2 website (svn update /mcs/web/research/projects/mpich2).

If this is a full release (e.g., 1.0.7, 1.0.8), update the MPICH2 website

  • Update the news and downloads sections on the main page as well as on their detailed description pages.
  • Update the user, install and windev guides.
  • Update the documentation pages to point to the right version.

Mark the milestone complete on TRAC

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

Send out the release announcement to mpich2-announce@mcs.anl.gov 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