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-treesh src/tools/version_stamp 22cvs 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/toolsedit version_stamp, update a variable assignment at its headcvs commit -m "Update version_stamp for 8.5"cd
../..shsrc/tools/version_stamp develcvs 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 4autoconfcvs 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