It's pretty simple, basically:

0) Form a branch in git:

	$ git tag branch-0_xx
	$ git branch Branch-0_xx
	$ git push origin branch-0_xx Branch-0_xx

   Use the form Branch-0_xx, where xx is the release number.

1) Change the version number in configure.ac, user guide and README.md.
2) Update web pages regarding purpose and status of rc.
3) Put out a release candidates until everyone's happy.
   jkl has a "make dist" script on /etc/nightly.freetds that works well.
4) ftp tarball to
	ftp://login.ibiblio.org/pub/linux/ALPHA/freetds/current
5) ftp user guide to www.freetds.org/userguide/.
   repeat 3-4 as necessary.
6) Log into ibiblio.  Trim rc# from tarball.  Update web site.
7) Create rpm with 'rpmbuild -ta freetds-0.61.tar.gz', post these as well.

Announcements to:

	freshmeat.net
	comp.os.linux.announce
	comp.databases.sybase
	comp.databases.ms-sqlserver
	linuxpr.com


We received this bit of advice on the mailing list on
Wed Oct 15 14:51:06 EDT 2003.

Please, please, *please* follow the common rules of good release
engineering (in descending order of importance - two orders of magnitude
less important per step ;-)

(A) (Priority 100) A release is STATIC.  You NEVER EVER change the
    contents of a release after the fact, such as replacing the
    freetds-0.61.tgz archive with a DIFFERENT ARCHIVE containing
    freetds-0.61.2.  This breaks everybody that has a system in place
    for using the tarballs - and I know of at least eight public open
    source systems that do this, as well as a bunch of proprietary systems.

(B) (Priority 1) Release engineering needs to include procedures to
    make sure that the documentation in the release is up to date.
    FreeTDS 0.61.2 refers to itself as FreeTDS 0.61.1.

(C) (Priority 0.01) It'd be nice if the archive name followed the normal
    convention for naming - .tar.gz for tar and gzip, rather than .tgz.

--
$Id$