Steps to preparing an ITAPS release

Here are the basic steps in preparing an ITAPS release.

  1. Ensure all stakeholders are prepared to make a release
    • An ITAPS release involves each stakeholder making a release of their products as well. Even if this is just the creation of a stable release candidate from a nightly, it is something all stakeholders need to be prepared to do.
    • In some cases, if it is not practical, its possible for ITAPS project to create its own private release of a stakeholder's product.
      • In that case, the tarball should be placed into the release_distros dir of the release candidate (see next step).
  2. Make a release candidate branch (RC). For example...
    svn copy -m 'making 1.2 release candidate' \
        https://redmine.scorec.rpi.edu/svn/itaps/software/trunk \
        https://redmine.scorec.rpi.edu/svn/itaps/software/branches/1.2RC
    
    • Note that when the release is finalized the final URL (target) will be a tag as in
          https://redmine.scorec.rpi.edu/svn/itaps/software/tags/1.2
      
  3. Ensure all developers working on the ITAPS repo know to work on the release candidate branch created in the step above and not the trunk.
    • The changes made on the RC will be merged to the trunk at a later step.
  4. Run weekly testing scripts, run_iMesh_test.sh and run_iMeshP_test.sh in the tools dir manually
    • Iterate with stakeholders on any issues that arise in testing
    • Stakeholders need to be responsive to address issues and cut new RC tarballs of their products
  5. Run the build_itaps script and update paths it uses to find products
  6. Draft the release notes for the ITAPS release
    • Typically, this consists of changes to API specifications, details on specific areas of focus of the release (e.g. "this release focuses on parallel iMeshP"), and other information users may potentially care about.
    • It also consists of lists of URL where various software components can be obtained.
  7. Iterate with stakeholders on the release notes
  8. When all tests are passing and/or failures are understood and deemed acceptable, the release candidate is ready. The final steps to making the release are
    1. Generate the doxygen reference manual content. From the tools/doxygen dir...
      $ doxygen dg_config
      

      This will modify and possibly add new files (if the installation of doxygen has changed since the last time this was done, it can result in big changes to the html dir's contents) in the html subdirectory.
      • Ensure all files have the svn:mime-type property set to text/html. If you don't do this, the content won't be browseable by most browsers. Most browsers will wind up treating it as plain text.
    2. Adjust build_itaps to build from the targetted tagged release instead of the RC and then commit that last change on the RC.
    3. Merge the release candidate to the turnk
      $ cd trunk
      $ svn update # make sure you have most up to date trunk
      $ svn merge https://redmine.scorec.rpi.edu/svn/itaps/software/branches/1.2RC
      $ svn diff # take a look at the diffs and see if they are what you expect
      $ svn commit -m 'merging my 1.2RC fixes to trunk'
      
    4. Tag the release
      $ svn copy -m 'tagging the 1.2 release' \
          https://redmine.scorec.rpi.edu/svn/itaps/software/branches/1.2RC \
          https://redmine.scorec.rpi.edu/svn/itaps/software/tags/1.2
      
    5. Post a News item to the Redmine site with the release notes
    6. Email the release notes to itaps-announce email
    7. Update the live web pages
      • This is accomplished by editing html content in the www dir of the itaps repo. Specifcally, www/current/software/download_interfaces.html.
      • Duplicate download_interfaces.html creating download_interfaces_A.B.html where A and B are the major and minor release numbers of the previous release, the one just before the one you are now making.
      • svn add the new html file you created above
      • Edit the new html file you created above making it a previous release page. That means you remove all the past release history in it. See some of the other previous release pages for examples of what it should look like.
      • Edit the original download_interfaces.html file in the following ways...
        • Update the current release number to the current release
        • Add a reference to the release notes news item you created above
        • Add a new line of history for the past release and point to the new html file you created above for it.
        • Find all references to the paths for tarballs, header files, etc in the file that point to the previous release and update them to point to the current release
        • svn commit the changes to this html content
      • Your changes should automatically go live after about 10 minutes. If they don't, there may be something wrong with the backend processes that handle this. Contact Tim Wickberg, , for help.