How to do a release: Difference between revisions
Ogg.k.ogg.k (talk | contribs) (mention make distcheck too) |
(→Tag in version control: add info about tagging with git) |
||
Line 8: | Line 8: | ||
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. | 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 | == Tag in version control == | ||
All official project releases must be tagged in | 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 | 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 == | == Prepare a tarball == |
Revision as of 17:31, 3 February 2010
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
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.