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
