These are some brief notes about how I've traditionally done releases of the opensource projects I created: sparsehash, ctemplate, gflags and python-gflags, and gperftools. They are intended for current maintainers of these projects, to do with as they like.

Release process

1. Update configure.ac with the new release number. For some projects, I also have to manually update the release number in src/windows/config.h, or in another file (eg src/pprof in gperftools). Also update the library version in configure.ac if appropriate.

2. Update the following files with the new release date and notes:

          NEWS
          ChangeLog
          packages/deb/changelog
          packages/deb/copyright
        

   All these files take a date. The easiest way to update the date is to just type in DDDD wherever the date is supposed to be, and run the following commands:

     
          export now=`date +%s`
          sed -i "s/DDDD/`date -d@$now +'%d %B %Y'`/" NEWS
          sed -i "s/DDDD/`date -d@$now +'%a %b %d %T %Y'`/" ChangeLog
          find . -name changelog -o -name copyright | xargs sed -i "s/DDDD/`date -d@$now -R`/"
        

3. Create the distribution files:

          make dist && make distcheck && make rpm && make deb && echo "ALL DONE"
        

   (I skip 'make distcheck' for gperftools, since it doesn't work on 64-bit machines.)

   Note: you may need to install various packages on your machine to run these. There may be easier ways to create the .rpm from the .deb than what I use now. Also note: if you have a 64-bit machine, this will create only 64-bit rpm and deb's. I create the 32-bit .deb and .rpm using a 32-bit-libc chroot setup on my machine. See below for details.

4. Assuming the above all complete without error, you can submit your svn changes. For releases, I just use the changelog as the submit message:

          # First, make sure the submit message looks ok
          perl -ple 'exit if /^\s*$/ && (++$count == 2)' ChangeLog
          perl -ple 'exit if /^\s*$/ && (++$count == 2)' ChangeLog | svn commit -F /dev/stdin
          export project=gperftools   # for example
          export version=2.1          # the version you're releasing
          svn copy https://$project.googlecode.com/svn/{trunk/,tags/$project-$version} -m "Tag for $project $version"
        

5. Use the following command to upload everything to Google Code:

          export project=gperftools # probably already did this in the previous step
          export version=2.1        # the version you're releasing
          export username=csilvers  # your google code username
          home/build/opensource/tools/googlecode_upload.py -p "$project" -u $username `find . -name '*'$version.tar.gz -o -name '*'$version'*.deb' -o -name '*'$version'*.rpm' -o -name '*'$version.zip -o -name '*'$version'*'.egg`
        

   I use a modified version of googlecode_upload.py, present here. There's also the standard version, but you'll need to modify the commandline above to use it. The modified version takes multiple files at once, automatically tags the subject line, and takes a first stab at identifying 'featured' files.

6. Go to the 'downloads' tab on the Google Code page, and edit the labels of the files you just uploaded. They should match the corresponding labels that already exist for the old version of the code (in particular, you can see which files are 'featured'). googlecode_updates.py should have auto-labeled some uploads for you. To edit labels, click on the summary (e.g. "Tarball for gperftools 2.0") and look at the bottom of the page.

7. Go to all old files that were previously in the 'downloads' tab, and edit all their labels to say 'deprecated'. For each one, either replace the existing 'featured' label by 'deprecated', or just add a new 'deprecated' label.

8. Go to the 'administer' tab on the google code page, and update the description textbox by adding in the new content from the top of the NEWS file. Go down to the bottom of the page and click on 'save changes'.

9. Go to the 'issues' tab on the google code page, and resolve any issues that have been fixed by this release. (I only mark issues 'fixed' when I do a release that has the fix in them. In retrospect, I probably should have had the policy of marking them fixed when the fix was submitted to SVN. If you do that, then you can skip this step.)

Creating a chroot environment

This works on debian x86_64 systems. It creates an i386 libc environment, to make it easy to test the opensource code on a 32-bit system, and also to create 32-bit .deb and .rpm files. These instructions are a bit old (when 'lenny' was the latest debian release) and may be slightly changed for newer releases.

Here are the commands to create the chroot environment:

echo $USER  # record USER for later
id -u       # record UID for later
sudo aptitude install debootstrap
sudo debootstrap --arch i386 lenny lenny-i386
sudo chroot lenny-i386 /bin/bash
aptitude update
aptitude install build-essential
[may want to install other things as well: autotools and automake? perl?]
useradd -u <UID> <USER>   # values from above

To test and build rpm/deb files in the chroot environment, just run the following command:

   export version=1.2    # the version number you're releasing
   ./build_in_chroot lenny-i386 *$version.tar.gz

This requires that you have the files build_in_chroot and build_in_chroot.helper in the current directory. You should of course replace lenny-i386 with the actual directory of the chroot environment you created above.

Using a testing lab

If you're lucky enough to have a fleet of machines with different CPUs/OSs available for testing, I have a tool that can help with that: test_on_machine.py, and its config file, machines.config. It takes a tarball and runs 'configure && make && make check' on each of the machines listed in the config file.