Release procedure added to HACKING

[Russ Allbery]

I've just added the following section to HACKING:

Making a Release

    This is a checklist that INN maintainers should go through when
    preparing a new release of INN.

    1.  If making a major release, branch the source tree and create a new
        STABLE branch tag.  This branch will be used for minor releases
        based on that major release and can be done a little while before
        the .0 release of that major release.  At the same time as the
        branch is cut, tag the trunk with a STABLE-<version>-branch marker
        tag so that it's easy to refer to the trunk at the time of the
        branch.

    2.  Update doc/pod/news.pod and regenerate NEWS.  Be more detailed for a
        minor release than for a major release.  For a major release, also
        add information on how to upgrade from the last major release,
        including anything special to be aware of.  (Minor releases
        shouldn't require any special care when upgrading.)

    3.  Make sure that support/config.sub and support/config.guess are the
        latest versions (from <ftp://ftp.gnu.org/gnu/config/>).  See the
        instructions in the section on "Configuring and Portability" for
        details on how to update these files.

    4.  Make sure that samples/control.ctl is in sync with the master
        version at <ftp://ftp.isc.org/pub/usenet/CONFIG/control.ctl>.

    5.  Check out a copy of the release branch.  It's currently necessary to
        run configure to generate Makefile.global.  Then run make
        check-manifest.  The only differences should be files that are
        generated by configure; if there are any other differences, fix the
        MANIFEST.

    6.  Run make release.  Note that you need to have a copy of cvs2cl from
        <http://www.red-bean.com/cvs2cl/> to do this.  You will be prompted
        for the release branch tag, the date from which to generate the
        ChangeLog, and the path to cvs2cl.  Start the ChangeLog slightly
        before the last release (we only ship inter-release change logs).

    7.  Make the resulting tar file available for testing in a non-listable
        directory on ftp.isc.org and announce its availability on
        inn-workers.  Install it on at least one system and make sure that
        system runs fine for at least a few days.  This is also a good time
        to send out a draft of the release announcement to inn-workers for
        proof-reading.

    8.  Generate a diff between this release and the previous release if
        feasible (always for minor releases, possibly not a good idea due to
        the length of the diff for major releases).

    9.  Move the release into the public area of the ftp site and update the
        inn.tar.gz link.  Make an MD5 checksum of the release tarball and
        put it on the ftp site as well, and update the inn.tar.gz.md5 link. 
        Put the diff up on the ftp site as well.  Contact the ISC folks to
        get the release PGP-signed.  Possibly move older releases off into
        the OLD directory.

    10. Announce the new release on inn-announce and in news.software.nntp.

    11. Tag the checked-out tree that was used for generating the release
        with a release tag (INN-<version>).

    12. Bump the revision number in Makefile.global.in.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>