Checking Things Before a Release

• Make sure all necessary merges have been done
• The VDT release should be cleared by the VDT testers group
• The VDT nightly test should report no significant errors
• Test optional components, like MySQL and others – VDT 1.2 only
• We should not have changed the Pacman cache for at least a day
• Make sure that the RPMs are all in place – not done for VDT 1.3 yet
• Make sure that the Debian packages are all in place – not done for VDT 1.3 yet
• Make sure that the licenses are in place on the web site
• Make sure that the Globus patches are in place on the web site
• Look at relevant documentation to make sure it's up to date
• Update any version numbers in defs that rely on the previous VDT version (example PERL_MODULES_VERSION)
• Make sure that we have re-run make-vdt on VDT-Version-Info to have the latest version numbers reported by vdt-version
• Make sure that we have re-run make-vdt on VDT-Certification-Tests to have the latest unsupported platform list for the nightly tests.
• Double-check all skipped-test counts and compare against the ones in nightly-tests.what/vdt-test-email

Releasing a New Version of the VDT

1. Set AFS permissions to protect the release directory from accidental updates

   afs_rseta /p/vdt/public/html/releases/RELEASE-VERSION condor:vdt rla
   afs_rseta /p/vdt/public/html/releases/RELEASE-VERSION condor:condor-admin rla
   

2. Update the symbolic link to the current development cache

   cd /p/vdt/public/html
   unlink vdt_dev_cache
   ln -s DEV-RELEASE-CACHE vdt_dev_cache

3. If this release is part of a stable series
   1. Update the symbolic link to the current stable cache

      cd /p/vdt/public/html
      unlink vdt_cache
      ln -s STABLE-RELEASE-CACHE vdt_cache

   2. Update the symbolic link to the current release directory

      cd /p/vdt/public/html/releases
      unlink current
      ln -s RELEASE-VERSION current

4. Update the /p/vdt/public/html/whats_new.html file
5. Edit stable_version or dev_version in the top-level autohandler file
6. Edit releases/autohandler to update the current, supported, pre-released, and frozen versions list.
7. Send email to vdt-discuss AT opensciencegrid.org, and osg-int AT opensciencegrid.org

Preparing for the Next Release

The instructions use SVNROOT to stand for the base URL to access the Subversion VDT repository. Currently, SVNROOT is

file:///p/vdt/workspace/svn/vdt

The first step is often done several days before the release is cut.

1. Get a new volume for the next release(s) by sending email to condor-mm

   To: condor-mm@cs.wisc.edu
   Subject: Request for another VDT release volume
   
   The VDT needs another AFS volume for a future release.  Please create
   it as follows:
   
   Mount: /p/vdt/public/html/releases/NEW-VERSION
   Size:  5 GB
   ACLs:  condor:vdt rlidwka
          condor:condor-admin rla
          system:administrators rlidwka
          system:anyuser rl
          condor rla
   
   Thank you!

2. Tag the release

   svn copy SVNROOT/trunk SVNROOT/tags/vdt-VERSION

   where VERSION is the dotted version number, such as “1.7.0”
3. Make the release branch
   • Stable series release
     1. For a new stable series release (x.y.0), make the series branch first:

        svn copy SVNROOT/trunk SVNROOT/branches/vdt-SERIES

        where SERIES is the two-part series prefix, such as “1.8”
     2. For all stable series releases, make the release branch:

        svn copy SVNROOT/branches/vdt-SERIES SVNROOT/branches/vdt-VERSION

        where SERIES is as above and VERSION is the dotted version number, such as “1.8.0”
   • Development series release

     svn copy SVNROOT/trunk SVNROOT/branches/vdt-VERSION

     where VERSION is the dotted version number, such as “1.7.1”
4. Check out the trunk

   svn checkout SVNROOT/trunk
   cd trunk

5. Update VDT_VERSION in defs

   #
   # Current VDT version
   #
   VDT_VERSION = NEW-VERSION

6. Initialize the new cache by running make-vdt on all packages:

   ./make-vdt */*.pacman

7. Once the cache has built successfully, verify that the symlink for the CA certificates is in place. It should point to /p/vdt/public/html/vdt_cert_cache/CA-Certificates-Base.pacman.

   ls -l /p/vdt/public/html/releases/NEW-VERSION/cache/CA-Certificates-Base.pacman

8. Send email to vdt-dev to say that the trunk has changed versions
9. Update the following files to switch tests to the new version (where TESTS is your checkout of $SVN/tests/trunk):

   TESTS/test-scripts/tests-to-run
   TESTS/web/index.html
   TESTS/vdt-test-email
   TESTS/send-mail.sh

   Be sure to run make to push out the changes
10. Copy the old documentation into the new release directory

    cd /p/vdt/public/html/releases
    cp -pr OLD-VERSION/*.html NEW-VERSION
    cp OLD-VERSION/notes/autohandler NEW-VERSION/notes

Making a Lettered Release of a Branch

1. Get a new checkout of the branch to be released

   svn co file:///p/condor/workspaces/vdt/svn/vdt/branches/BRANCH

2. Change defs file to reflect correct version and release letter
3. Make the list of packages that you will need to update. There are two equivalent methods: use both and cross check.
   1. Look through SVN commits since last release. Note changes to defs files: these might imply changes to a package that didn't have a SVN commit. Double-note things like a change to the GUMS package: GUMS isn't re-made, but GUMS-Server and GUMS-Client are.
   2. Find all changed files in SVN with subversion.

      svn diff --summarize file:///p/condor/workspaces/vdt/svn/vdt/tags/PREVIOUS-TAG file:///p/condor/workspaces/vdt/svn/vdt/branches/BRANCH

   3. Add VDT-Version-Info and VDT-Certification-Tests to the list. They usually need to be rebuilt but may not have been touched in subversion.
4. Make the release cache writable

   afs_rseta /p/vdt/public/html/releases/RELEASE-VERSION condor:vdt rlidwka

5. Run make-vdt on the list you generated before.
6. Find and fix symbolic link problems.
   1. Edit /p/condor/workspaces/vdt/bin/find-cache-problems to ensure that it checks for the proper "bad" directory. At the moment it is hard coded to check against 1.10.99 as the bad directory.
   2. Generate a list of files that need fixing:

      /p/condor/workspaces/vdt/bin/find-cache-problems RELEASE-VERSION

   3. Fix the files using the following command. Note that the LIST-OF-FILES should be the files in /p/vdt/public/html/software/ that were indented from the output of find-cache-problems, not the files in /p/vdt/public/html/releases/RELEASE-VERSION/cache/*.pacman. The files should be full, absolute paths.

      /p/condor/workspaces/vdt/bin/new-move-binary RELEASE-VERSION LIST-OF-FILES

7. Lock permissions on the release cache

   afs_rseta /p/vdt/public/html/releases/RELEASE-VERSION condor:vdt rla

8. Run test upgrades and kick off the test suite (if applicable).
9. Tag the release

   svn copy file:///p/condor/workspaces/vdt/svn/vdt/branches/BRANCH file:///p/condor/workspaces/vdt/svn/vdt/tags/TAG

   Where TAG is something like vdt-1.8.0a

10. Write release notes and add to existing release notes document (may need to unlock the directory for this)

    fs setacl /p/vdt/public/html/releases/VERSION condor:vdt rlidwka
    cd /p/vdt/public/html/releases/VERSION
    cp release-letter.html release-LETTER.html
    edit release-LETTER.html
    edit release.html (point to release-LETTER.html)

11. Relock the release directory when finished editing the release notes.

    afs_rseta /p/vdt/public/html/releases/RELEASE-VERSION condor:vdt rla

12. Update the What's New? page.

    edit /p/vdt/public/html/whats_new.html

13. Announce the release
    • vdt-discuss@opensciencegrid.org (subscription information)
    • goc@opensciencegrid.org
14. If necessary, merge the changes into the appropriate branch.