Re: Automating our version-stamping a bit better
От | Tom Lane |
---|---|
Тема | Re: Automating our version-stamping a bit better |
Дата | |
Msg-id | 24817.1213132539@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Automating our version-stamping a bit better (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: [CORE] Automating our version-stamping a bit
better
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: