[HACKERS] Automating our version-stamping a bit better

So while tagging the upcoming releases, I got annoyed once again about
what a tedious, error-prone bit of donkeywork it is. You've got to find
and update the sub-version numbers, and *not* any chance occurrence of
the same strings (eg s/20/21/g for version 7.4.21 would've mangled some
copyright dates). And the changes tend to move around a little bit in
each back branch, making it even easier to blow it. ISTM we should get
the machine to do it for us.

I propose to write a little perl script to be used like this:

cd top-level-of-tree
sh src/tools/version_stamp 22
cvs commit -m "Stamp release 7.4.22"

The script takes just one argument, which could be "devel", "betaN",
"rcN", or just a minor version number "N". Note the assumption that the
script knows the major version. Since we expect to adjust the script
from time to time for version changes anyway, I don't see why we
shouldn't have the major version stored right in the script. Tagging a
new development branch after a release is split off would then look like

cd src/tools
edit version_stamp, update a variable assignment at its head
cvs commit -m "Update version_stamp for 8.5"
cd ../..
sh src/tools/version_stamp devel
cvs commit -m "Stamp CVS HEAD as 8.5devel"

Note that this is not all that helpful if we just do it in CVS HEAD.
I propose adding the script to all active branches back to 7.4, with
suitable adjustments for each branch as needed.

I think we should probably include configure.in in the set of files
that this script updates, and get rid of the current two-step
arrangement where Marc stamps configure.in/configure after somebody
else stamps everything else. Marc's tarball-wrapping process would
thus look roughly like

sh src/tools/version_stamp 4
autoconf
cvs commit -m "Stamp release 8.3.4"
cvs tag REL8_3_4
... build tarball ...

I'm tempted to suggest letting the script invoke autoconf, too,
but that would require standardizing where to find the correct
version of autoconf for each branch; so it might not be such a
great idea.

Thoughts, objections?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers