Note: This web site is only kept up to date for OSG Software 1.2 (VDT 2.0.0). If you are looking for information for the most recent release, the RPM-based OSG Software 3.0, please see the OSG documentation web site

Checking Things Before a Release

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:  10 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 and PRODUCTION_VERSION in defs
    #
    # Current VDT version
    #
    VDT_VERSION = NEW-VERSION
    PRODUCTION_VERSION = NEW-VERSION
  6. Initialize the new cache by running make-vdt on all packages:
    ./make-vdt */*.pacman
  7. Send email to vdt-dev to say that the trunk has changed versions
  8. 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/send-mail.sh
    Be sure to run make to push out the changes
  9. 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