How to Cut a Release

Due to the length of time that this process takes, it is recommended to do the release over two days to allow for errors to be corrected and because some of the koji commands take a long time to run when a large number of rpms are being released.

This document doesn't discuss the policy for deciding what goes into a release. The release policy is discussed elsewhere.

NOTE Interactive scripts can be found at and can be checked out with SVN.

Pick the version number

This page will help you get the various commands exactly right. To do this, enter the exact version number (such as 3.0.5) and click submit. If you do not do this, the commands below will be missing essential text.

Version: Upcoming:

Day 0

Step 1: Update the osg-version RPM

Edit the osg-version RPM's spec file to update the version number to VERSION. Build it in koji:

# If building for the latest release out of trunk:
osg-build koji osg-version
# If building for an older release out of a branch:
osg-build koji --repo=VERSION osg-version

Step 2: Generate the tentative release list

The release manager often needs a preliminary list of packages slated for the next release a few weeks in advance. This is done by finding the package differences between what's in testing and what's in the current release. There is a script in SVN that handles this:

./0-generate-pkg-list VERSION

Day 1: Verify Pre-Release and Testing

Step 1: Verify Pre-Release

You will need to compare the list of packages already in pre-release to the final list for the release put together by the OSG Release Coordinator. You can use the 1-list-prerelease script from SVN:

./1-list-prerelease VERSION

If there are any discrepancies you may have to tag or untag packages with the osg-koji tool.

NOTE: Please verify that the osg-version RPM is in your set of packages for the release! Also verify that if there is a new version of the osg-tested-internal RPM, then it is included in the release as well!

Step 2: Test Pre-Release in VM Universe

To test pre-release, you will be kicking off a manual VM universe test run from

  1. Make sure you meet the pre-requisites for submitting VM universe test runs
  2. Prepare the test suite by running:
    osg-run-tests 'Testing OSG pre-release'
  3. cd into the directory specified in the output of the previous command
  4. cd into parameters.d and remove all files within it except for standard-params.yaml, osg33-el6.yaml, and osg33-el7.yaml
  5. Edit standard-params.yaml so that it reads:
      - centos_5_x86_64
      - centos_6_x86_64
      - rhel_5_x86_64
      - rhel_6_x86_64
      - sl_5_x86_64
      - sl_6_x86_64
      - 3.2; osg-prerelease                      # Tests clean installs of 3.2 pre-release
      - 3.2; osg > osg-prerelease                # Tests update installs of 3.2 pre-release
      - 3.1; osg > 3.2/osg-prerelease            # Tests update installs between 3.1 and 3.2 pre-release
      - [java-1.7.0-openjdk-devel, osg-java7-compat, osg-java7-devel-compat, osg-tested-internal]
  6. Edit osg33-el6.yaml so that it reads:
      - centos_6_x86_64
      - rhel_6_x86_64
      - sl_6_x86_64
      - 3.3; osg-prerelease                      # Tests clean installs of 3.3 pre-release
      - 3.3; osg > osg-prerelease                # Tests update installs of 3.3 pre-release
      - 3.2; osg > 3.3/osg-prerelease            # Tests update installs between 3.2 and 3.3 pre-release
      - 3.1; osg > 3.3/osg-prerelease            # Tests update installs between 3.1 and 3.3 pre-release  
      - [java-1.7.0-openjdk-devel, osg-java7-compat, osg-java7-devel-compat, osg-tested-internal]
  7. Edit osg33-el7.yaml so that it reads:
      - centos_7_x86_64
      - rhel_7_x86_64
      - sl_7_x86_64
      - 3.3; osg-prerelease                      # Tests clean installs of 3.3 pre-release
      - 3.3; osg > osg-prerelease                # Tests update installs of 3.3 pre-release
      - [java-1.7.0-openjdk-devel, osg-java7-compat, osg-java7-devel-compat, osg-tested-internal]
  8. cd back into the root directory of the test run (e.g. cd ..)
  9. Submit the DAG:
    condor_submit_dag master-run.dag

NOTE: If there are failures, consult the release-manager before proceeding.

Step 2: Create the client tarballs

Create the client tarballs using the scripts in software/tarball-client/trunk from our SVN, and then copy them into the UW's AFS. Do this as root on an EL6 fermicloud machine. Change the username and machine name as appropriate. Note: the prerelease repos must have been populated and regenerated for this to work; normally that happens in Step 2.

yum -y install subversion yum-priorities
mkdir -p /tmp/tarball-client
cd /tmp/tarball-client
svn export
trunk/make-client-tarball --osgver=VERSION --prerelease --all
scp -p *.i386.tar.gz $ruser@$rmachine:/p/vdt/public/html/tarball-client/VERSION/i386
scp -p *.x86_64.tar.gz $ruser@$rmachine:/p/vdt/public/html/tarball-client/VERSION/x86_64
You should get 8 tarballs, 30-55 megs each. They should all have VERSION in the name.

NOTE If you are running into 404 errors concerning specific packages, this may be due to stale build repos. To regenerate the build repos, run:

[user@client ~]$ osg-koji regen-repo osg-<osg version>-<distro version>-release-build

For example, run the following command to regenerate the OSG 3.2 EL6 build repo:

[user@client ~]$ osg-koji regen-repo osg-3.2-el6-release-build

Step 3: Briefly test the client tarballs

As an unprivileged user, extract each tarball into a separate directory. Make sure osg-post-install works. Make sure 'osgrun osg-version' works.

For 3.2:

for client in osg-client osg-wn-client; do
    for rhel in el5 el6; do
        for arch in i386 x86_64; do
            mkdir -p $rhel-$arch
            pushd $rhel-$arch
            tar xzf ../$file
            $client/osgrun osg-version

For 3.3:

dotest () {
    mkdir -p $rhel-$arch
    pushd $rhel-$arch
    tar xzf ../$file
    $client/osgrun osg-version
for client in osg-afs-client osg-wn-client; do
    for rhel in el6 el7; do


If you have time, try some of the binaries, such as grid-proxy-init.

NOTE: We need to automate this and have it run on the proper architectures and version of RHEL.

Step 4: Update the UW AFS installation of the tarball client

The UW keeps an install of the tarball client in /p/vdt/workspace/tarball-client on the UW's AFS. There is a script to update it called afs-install-tarball-client. Run it as follows:

/p/vdt/workspace/tarball-client/afs-install-tarball-client VERSION

Step 5: Remove old UW AFS installations of the tarball client

To keep space usage down, remove tarball client installations and symlinks under /p/vdt/workspace/tarball-client that are more than 2 months old. The following command can list them:

find  /p/vdt/workspace/tarball-client  -maxdepth 1  -mtime +60  -name 3\*  -ls

Step 6: Wait

Wait for clearance. The OSG Release Coordinator (in consultation with the Software Team and any testers) need to sign off on the update before it is released. If you are releasing things over two days, this is a good place to stop for the day.

Day 2: Pushing the Release

NOTE: For the second phase of the release, try to complete it earlier in the day rather than later. The GOC would like to send out the release announcement prior to 3 p.m. their time (Eastern time zone), which means that our procedure needs to be completed before then.

Step 1: Push from pre-release to release

This script moves the packages into release, clones release into a new VERSION specific release repo, locks the new repo and regenerates it. Afterwards, it produces *release-note* files that should be given to whomever's writing the release notes.

./2-create-release VERSION

*.txt files are also created and it should be verified that they've been moved to /p/vdt/public/html/release-info/ on UW's AFS. There is also a section of the release notes that lists the packages that have been updated. To get this list, run:

list-package-updates VERSION

Step 2: Upload the client tarballs

Ask Mat or someone with privileges on the repo servers to upload the tarballs with the following procedure:

On a CS machine

cd /p/vdt/public/html/tarball-client
ssh mkdir /tmp/VERSION/
scp -p VERSION/*/*VERSION*gz


scp -pr /tmp/VERSION repo1:/tmp/
scp -pr /tmp/VERSION repo2:/tmp/
rm -rf /tmp/VERSION

On repo1/repo2 (as root)

You can ssh to repo1 and repo2 from; you will need to do this procedure on both systems.
sudo su -
mv /tmp/VERSION /usr/local/repo/tarball-install/VERSION/
rm -f /usr/local/repo/tarball-install/VERSION/*latest*
ls -l /usr/local/repo/tarball-install/VERSION/*latest* # verify the symlinks are correct

Step 3: Install the tarballs into OASIS

You must be an OASIS manager of the 'mis' VO to do these steps. Known managers as of 2014-07-22: Mat, Tim C, Tim T, Brian L. Get the uploader script from SVN and run it with osgrun from the UW AFS install of the tarball client you made earlier. On a UW CSL machine:

svn cat file:///p/vdt/workspace/svn/software/tarball-client/trunk/upload-tarballs-to-oasis > /tmp/upload-tarballs-to-oasis
chmod +x /tmp/upload-tarballs-to-oasis
/p/vdt/workspace/tarball-client/current/sys/osgrun /tmp/upload-tarballs-to-oasis VERSION
The script will automatically ssh you to and give you instructions to complete the process.

Step 4: Announce the release

The following instructions are meant for the release manager (or interim release manager). If you are not the release manager, let the release manager know that they can announce the release.

  1. The release manager writes the release announcement and send it out. Here is a sample:

    Subject: Announcing OSG Software version VERSION

    We are pleased to announce OSG Software version VERSION!

    This is the new OSG Software distributed via RPMs for:

    * Scientific Linux 5 and 6
    * CentOS 5 and 6
    * Red Hat Enterprise Linux 5 and 6

    This release affects the SET-OF-METAPACKAGES (client, compute element, etc...). Changes include:

    * Major change 1
    * Major change 2
    * Major change 3

    Release notes and pointers to more documentation can be found at:

    Need help? Let us know:

    We welcome feedback on this release!

  2. The release manager emails the announcement to
  3. The release manager asks the GOC to distribute the announcement by opening a ticket
  4. The release manager closes the tickets marked 'Ready for Release' in the release's JIRA filter
  5. The release manager updates the recent/scheduled release tables on the Software/Release homepage

Topic revision: r100 - 29 Sep 2015 - 21:57:45 - MatyasSelmeci
Hello, TWikiGuest


TWiki | Report Bugs | Privacy Policy

This site is powered by the TWiki collaboration platformCopyright by the contributing authors. All material on this collaboration platform is the property of the contributing authors..