Thread: 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
Tom Lane wrote: > > 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. > > Unfortunately that's true. Maybe we could agree on using an alias for the right version of autoconf, but it seems likely to be error prone. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> 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.
> Unfortunately that's true. Maybe we could agree on using an alias for
> the right version of autoconf, but it seems likely to be error prone.
Actually, the way I do things is that my setup script for working
with each particular version tree includes adjusting $PATH so that
the right autoconf gets found just by saying "autoconf". If everyone
who might tag releases wanted to do it the same way, then we could
just let the script say "autoconf". But I'm not sure anybody else
likes that plan. What I was thinking was just to have the script
print out something like
Tagged tree as 8.3.4Don't forget to run autoconf 2.59 before committing
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Sunday, June 08, 2008 21:27:03 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> Tom Lane wrote: >>> 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. > >> Unfortunately that's true. Maybe we could agree on using an alias for >> the right version of autoconf, but it seems likely to be error prone. > > Actually, the way I do things is that my setup script for working > with each particular version tree includes adjusting $PATH so that > the right autoconf gets found just by saying "autoconf". If everyone > who might tag releases wanted to do it the same way, then we could > just let the script say "autoconf". But I'm not sure anybody else > likes that plan. What I was thinking was just to have the script > print out something like > > Tagged tree as 8.3.4 > Don't forget to run autoconf 2.59 before committing I like that one ... - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhMj4MACgkQ4QvfyHIvDvNWAACfeEuX8PCwbPgZLutpya859T+5 sDYAoKgTnLoypgDOwr4TSYVd+G5Dn+kn =Cl6d -----END PGP SIGNATURE-----
Andrew Dunstan wrote: > Tom Lane wrote: >> >> 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. > > Unfortunately that's true. Maybe we could agree on using an alias for > the right version of autoconf, but it seems likely to be error prone. Or we could sidestep the issue by not running autoconf, but search-replace the version strings in configure directly with the perl script. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
"Marc G. Fournier" <scrappy@hub.org> writes:
> Tom Lane wrote:
>> What I was thinking was just to have the script
>> print out something like
>>
>> Tagged tree as 8.3.4
>> Don't forget to run autoconf 2.59 before committing
> I like that one ...
I've checked in a script to do this --- executingsrc/tools/version_stamp.pl N
at the top level of the tree should stamp everything needed, and remind
you which autoconf version to run.
Marc, you'll presumably be the primary user of this script, so would you
please try it out and make sure (a) it works for you, and (b) you like
the way it works? I don't think I used any unportable perl or sed
constructs, but let's find the problems now, not when we're trying to
wrap a release ...
regards, tom lane
Am Monday, 9. June 2008 schrieb Tom Lane: > So while tagging the upcoming releases, I got annoyed once again about > what a tedious, error-prone bit of donkeywork it is. Could you explain what the problem is? Your script sounds like an ad hoc workaround for some problem, but I haven't seen the problem actually defined.
Peter Eisentraut <peter_e@gmx.net> writes:
> Am Monday, 9. June 2008 schrieb Tom Lane:
>> So while tagging the upcoming releases, I got annoyed once again about
>> what a tedious, error-prone bit of donkeywork it is.
> Could you explain what the problem is? Your script sounds like an ad hoc
> workaround for some problem, but I haven't seen the problem actually defined.
The problem is having to manually insert the version number into half a
dozen different files, in half a dozen different formats, while
preparing an update release. (And multiply that by several back
branches, with several slightly different sets of changes to make.)
This is not only tedious but quite error-prone --- if you check the CVS
logs for the affected files you'll note we have missed changes more than
once. I don't think we've yet wrapped a mis-labeled tarball, but it's
going to happen sooner or later if we keep doing this manually.
I suspect you are wondering why we don't use the makefile infrastructure
to fix the numbers instead. I think the reason is that most of the
files in question are for Windows and we can't assume very much about
the available tools for fixing them at build time. In any case, I'd
be hesitant to back-patch such a fix. Doing it this way means that the
script only has to work on our own machines, not in any weird build
environment someone might have, so it seems a lot safer to drop into
the back branches.
regards, tom lane
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Am Monday, 9. June 2008 schrieb Tom Lane: > >> So while tagging the upcoming releases, I got annoyed once again about > >> what a tedious, error-prone bit of donkeywork it is. > > > Could you explain what the problem is? Your script sounds like an ad hoc > > workaround for some problem, but I haven't seen the problem actually defined. > > The problem is having to manually insert the version number into half a > dozen different files, in half a dozen different formats, while > preparing an update release. (And multiply that by several back > branches, with several slightly different sets of changes to make.) > This is not only tedious but quite error-prone --- if you check the CVS > logs for the affected files you'll note we have missed changes more than > once. I don't think we've yet wrapped a mis-labeled tarball, but it's > going to happen sooner or later if we keep doing this manually. > > I suspect you are wondering why we don't use the makefile infrastructure > to fix the numbers instead. I think the reason is that most of the > files in question are for Windows and we can't assume very much about > the available tools for fixing them at build time. In any case, I'd > be hesitant to back-patch such a fix. Doing it this way means that the > script only has to work on our own machines, not in any weird build > environment someone might have, so it seems a lot safer to drop into > the back branches. Yes, I like the idea of automating this. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +