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 SVN
All official project releases must be tagged in SVN. This is done using the SVN copy tag; essentially a versioned copy of a specific module/brach is copied to the tags directory in SNV. For example, the libvorbis 1.2.2 release was tagged using:
Prepare a tarball
./autogen.sh make dist
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):
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
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:
If everything is ok (and the checksums for other files have not changed), commit:
Add downloadable files
After about 30(?) minutes repository changes will be visible on
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.
Then you should update the download section on the Xiph website. The downloads page is in the normal svn repository for www.xiph.org:
Update it with your release tarball name and checksum, and commit.
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
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 <email@example.com>
- comp.os.linux.announce <firstname.lastname@example.org>
- <other suitable places>
It might also be a good idea to notify people maintaining ports of your project.