How to do a release

You made a new release, the world is waiting for it. Here is what to do:

Update versions and CHANGES files

Verify all project release versions embedded throughout the source and build system have been updated to appropriate values for the release. For projects that use the autotools, this means checking configure.in/configure.ac for AC_INIT, *LIB_CURRENT, *LIB_REVISION and *LIB_AGE. Depending on the project, there might be a version.h file, vendor or lib version strings embedded in the source somewhere (eg, lib/info.c for libvorbis or lib/internal.h for libtheora) and various other build project files for non-UNIX platforms (eg, macosx/Info.plist).

Changes, additions, improvements, and major bugfixes should be summarized in the CHANGES file. A good way to avoid missing anything is to look through the SVN log since last release and cherrypick the bits that would be of interest to outside developers or project managers.

Tag in version control

All official project releases must be tagged in their version control system.

Subversion

Tagging is done using the SVN copy tag; essentially a versioned copy of a specific module/brach is copied to the tags directory in SVN. For example, the libvorbis 1.2.2 release was tagged using:

 svn copy http://svn.xiph.org/trunk/vorbis@16168 http://svn.xiph.org/tags/vorbis/libvorbis-1.2.2

Git

To create a tag called "1.0.0" for the commit at the HEAD of master:

 git tag -a 1.0.0 master

You will be prompted to write a message describing the tag.

When you push your changes to git.xiph.org you must specify to also push tags; eg. for a remote named "xiph":

 git push --tags xiph

Prepare a tarball

./autogen.sh
make dist

If a distcheck target is available, then it should be used instead, as it can spot common mistakes:

./autogen.sh
make distcheck

Ideally, offer binaries for the different systems. This is not required, and many packages (such as libvorbis, etc) ship only as source releases. If in doubt, do what previous releases did. If there are no previous releases, libs usually ship as source only, applications tend to offer binaries.

Create a release directory under http://svn.xiph.org/releases/

If you are uploading the first release of a project to Xiph.org, then first create a release directory in the svn repository. You can do this using remote svn commands (rather than checking out the entire Xiph.org release archive):

 svn mkdir https://svn.xiph.org/releases/PROJECTNAME

Then check that directory out locally:

 svn co https://svn.xiph.org/releases/PROJECTNAME PROJECTNAME-releases

Add new release files

Add tarballs etc. to your local checkout of the release directory:

 cd PROJECTNAME-releases
 svn add PROJECTNAME-x.x.x.tar.gz

Depending on your svn client, you may need to explicitly set the mime-type:

 svn propset svn:mime-type application/octet-stream *.tar.gz

Then, generate MD5 and SHA1 checksums for these files. Extending the checksum files is easy on a Unix machine:

 md5sum PROJECTNAME-x.x.x.tar.gz >> MD5SUMS
 sha1sum PROJECTNAME-x.x.x.tar.gz >> SHA1SUMS

Check that the only modifications to the checksums are for the new files:

 svn diff

If everything is ok (and the checksums for other files have not changed), commit:

 svn commit

Website update

Add downloadable files

After about 30(?) minutes repository changes will be visible on

http://downloads.xiph.org/releases/YOUR-COMPONENT/

immediate mirror update

The mirrorpush is performed by an every-half-hour cron task. If, for some reason, it's important to update the mirrors immediately, the following may be run as root on Motherfish to force-push:

cd /home/mirrorpush; ./update_downloads.sh

The script must be run from the /home/mirrorpush directory.

Update HTML

Update http://www.xiph.org/downloads/

Then you should update the download section on the Xiph website. The downloads page is in the normal svn repository for www.xiph.org:

 svn co https://svn.xiph.org/websites/xiph.org/downloads/

Update it with your release tarball name and checksum, and commit.

News page

New releases of official projects should include an announcement. The same announcement that is sent to the email announcement lists is used as the basis for a 'press release' on the Xiph news/press page. New news entries must be added seperately to the press page and the Xiph front page. Theora-related releases should also be added to the Theora News page.

The various xiph.org web sites must be edited through SVN just like the release download files. The websites can be found under svn.xiph.org/websites/.

immediate HTML update

Website changes are updated by a cron script like the download mirrors. To force an immediate website update, perform the following as root on Motherfish:

 cd /var/www; ./update_websites.sh

Announcement

Announce your release where apropriate. This can include

• The various Xiph.Org website news pages; see above.
• The Xiph Announce mailing list
• your blog
• the project's FreshMeat page
• Linux Weekly News <lwn@lwn.net>
• comp.os.linux.announce <cola@stump.algebra.com>
• <other suitable places>

It might also be a good idea to notify people maintaining ports of your project.

See Also

• CodingGuidelines
• MIT approach to design and implementation