From Apache OpenOffice Wiki
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 <firstname.lastname@example.org> * 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* email@example.com:/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.