Re: [CORE] [HACKERS] Automating our version-stamping a bit better
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] 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 [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] Automating our version-stamping a bit better
Marc G. Fournier [EMAIL PROTECTED] 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 --- executing src/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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Automating our version-stamping a bit better
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Automating our version-stamping a bit better
Peter Eisentraut [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Automating our version-stamping a bit better
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[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
Re: [HACKERS] Automating our version-stamping a bit better
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Automating our version-stamping a bit better
Andrew Dunstan [EMAIL PROTECTED] 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 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
Re: [CORE] [HACKERS] Automating our version-stamping a bit better
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Sunday, June 08, 2008 21:27:03 -0400 Tom Lane [EMAIL PROTECTED] wrote: Andrew Dunstan [EMAIL PROTECTED] 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. FournierHub.Org Hosting Solutions S.A. (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhMj4MACgkQ4QvfyHIvDvNWAACfeEuX8PCwbPgZLutpya859T+5 sDYAoKgTnLoypgDOwr4TSYVd+G5Dn+kn =Cl6d -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
