Re: Release stamping (Was: [CORE] Schedule for release?)

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Release stamping (Was: [CORE] Schedule for release?)
Дата
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA0FCC4@algol.sollentuna.se
обсуждение исходный текст
Ответ на Re: Release stamping (Was: [CORE] Schedule for release?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Release stamping (Was: [CORE] Schedule for release?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Release stamping (Was: [CORE] Schedule for  (Dave Page <dpage@vale-housing.co.uk>)
Список pgsql-hackers
> >> Sorry - we're just talking about getting the version
> number in there
> >> automatically to avoid it getting forgotten during release
> bundling.
>
> > I can see that being a good idea. But I don't see Toms ./configure
> > solution working.
>
> Why not?  The shipped tarball would contain exactly the same
> pg_config.h.win32 it does today; the only difference is that
> the version info would've been inserted automatically instead
> of manually.
> (The start of this discussion was my observation that
> pg_config.h.win32 contains multiple copies of the version
> info, and sooner or later somebody would miss one while
> stamping a release.)

Right. And then you can only build from tarball and not from CVS, right?
Because the pg_config.h.win32 with version is actually in cvs. Or an I
missing something here?


> > What we could do is have the msvc build scripts edit the file and
> > replace the version with something it reads from
> configure.in when run.
>
> That's great if you're using msvc, but what about borland?

Good point. But we could always make that part of the script a separate
one that can be run for Borland as welll.

//Magnus


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: [SPAM?] Re: Asynchronous I/O Support
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Release stamping (Was: [CORE] Schedule for release?)