Chapter 19. Making a Release
Prev | Part IV. Lire Developers' Conventions | Next

## Chapter 19. Making a Release

Before making an official Lire release, it should have been tested on all supported platforms. A release shouldn't be made unless Lire builds, installs and generates an ASCII report from all supported log files on all supported platforms. If this is not the case, the release should be delayed untill this is fixed.

Making a new release of Lire involves many steps:

1. Writing the final version number in NEWS.

2. Tagging the CVS tree.

3. Building the "Standard" Lire tarball.

4. Building the Debian GNU/Linux™ package.

5. Building the RPM package.

6. Making sure the FreeBSD package gets updated.

7. Uploading the tarballs and making packages available.

8. Advertising the release.

## Setting version in NEWS file, checking ChangeLog

Inbetween releases, the NEWS file generally reads "version in cvs". This should of course be changed to e.g. "version 20011205".

We maintain a ChangeLog file. Make sure the ChangeLog in the toplevel directory is not too big. If needed, split off a chunk and move it to doc/. The ChangeLog is autogenerated from the CVS commits, using the cvs2cl tool. One could e.g. run `cvs2cl --prune --stdout -l "-d \>yesterday" -U ../CVSROOT/users`. Beware! It might take SourceForge about a day to make the cvs log available. So you might have to wait a day between your last commit and running cvs2cl.

Prev | Up | Next
Using the Perl debugger on Lire code | Home | Tagging the CVS