> There's some sort of near-recursive problem here, where, at present, we
> choose between:
> 
> 1.  Needing to remember to run autoconf and check in changes *before*
> tagging, which is "brain-o"-vulnerable, or
> 
> 2.  Needing to run autoconf before trying to use a newly-tagged build.
> 
> It seems to me that PACKAGE_VERSION shouldn't need to be so embedded in
> autoconf.
> 
> The tag surely should be able to be picked up irrespective of doing an
> autoconf run...

I broke down and wrote a shell script for myself which would search for
new tags prefixed with a key indicating it's a release (RELENG_ in this
case); checkout the tagged tree; delete the tag via cvs tag -d; run
autoconf, automake, changelog, etc.; commit the newly changed files
generated; add the tag again (thus bumping to include the new versions);
then build a tarball with the newest tagged source; and then shoot off
an email indicating it's done and the file location.

I'm debating integrating an automated regression test run into the above
as well and aborting if it fails.

I suppose you could lose your tag position, but odds are the code your
about to release isn't moving anywhere on the system you originally
tagged it from, so it could be redone. Plus, it's next to impossible for
the new guy to screw up because there is very little to remember.
--