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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Automating our version-stamping a bit better
Следующее
От: Teodor Sigaev
Дата:
Сообщение: Re: Proposal: GiST constraints