Ooo-build/releasing

When there's a particularly good reason for a release, such as a distro needs a stable base or we want to do something potentially disruptive, one of the core ooo-build hackers will follow something like this process:

• cvs update - get the latest everything

• Read back through the ChangeLog and update the NEWS file for the release, summarizing and attributing the changes.

• edit configure.in, bump the version in the AC_INIT line, incrementing the minor version eg. AC_INIT(ooo-build, X.Y.Z)

• Add a line to any handy ChangeLogs, so we can easily see where this happened in the flow:

    2019-13-33  Ned Squeers  <ned@sqeers.com>

            * Version X.Y.Z

• ./autogen.sh - this re-builds configure with the version in place; a distro must be specified eg. ./autogen.sh --with-distro=SUSE

• make dist - this builds the archive containing everything.

• cvs commit - so what's there is what's there. If there was a collision you get to loop to the first stage here, but don't re-increment the number.

• cvs -z3 tag OOO_BUILD_X_Y_Z - this leaves a static tag so we can reproduce the build at any time and easily diff between releases.

• md5sum ooo-build-X.Y.Z.tar.gz > ooo-build-X.Y.Z.tar.gz.md5 - so that users can do at least the basic consistency check

• scp ooo-build-X.Y.Z.tar.gz* ooo@go-oo.org:/var/www/packages/<MWS_DIR>/ - uploads the tarball and the .md5 file for the right Master Work Space, eg. SRC680

• It's then customary to announce the release, see the template in doc/announce.txt - update all the ***s to the right versions, insert the contents of NEWS, fire and forget.