Re: win32 version info - Mailing list pgsql-patches
From | Mark Cave-Ayland |
---|---|
Subject | Re: win32 version info |
Date | |
Msg-id | 8F4A22E017460A458DB7BBAB65CA6AE5026623@openmanage Whole thread Raw |
In response to | win32 version info ("Magnus Hagander" <mha@sollentuna.net>) |
List | pgsql-patches |
> -----Original Message----- > From: pgsql-patches-owner@postgresql.org > [mailto:pgsql-patches-owner@postgresql.org] On Behalf Of > Magnus Hagander > Sent: 30 July 2004 09:58 > To: Peter Eisentraut > Cc: Andrew Dunstan; pgsql-patches@postgresql.org > Subject: Re: [PATCHES] win32 version info > > > > > Perhaps a compromise would be to set versioninfo on > > libpq.dll (which > > > we alerady do), and on all the EXEs, and ignore the rest of > > the DLLs. > > > It's not ideal, but it's a great deal better than nothing at all. > > > > If that is an option, why not just put versions into the > > build-time linkable DLLs, which really need a version, and > > leave it out for the rest. Clearly, we cannot put a version > > into every file anyway (headers files, etc.), so "everything > > must have a version" does not hold anyway, unless there is > > some weird rule again that certain things must have one. > > As for DLLs, yes, that sounds reasonable. We also need to put > it on the EXEs. That would mean which DLLS? libpq.dll and > pgevent.dll definitly. Any of the ecpg dlls? > > If we limit ourselves to these libs, are you fine with > keeping the 7.5.x version numbering there? (As said before, > for libpq we don't have much choice, and pgevent.dll has no > other versioning scheme anyway, since it's brand new and win32 only) > > > As said, not ideal, but good enough I think. I think the rule > generally is any EXE and DLL. But as long as it's a private > DLL that nobody else ever uses, I think it's reasonable to > skip the rule there. > > //Magnus I've just had a look at a Linux install of 7.4.2 and the version numbering that is present in the /lib and /bin directories. To make things consistent, I would suggest the following approach for applying version information on a per directory basis: /bin - release numbering, e.g. 7.5.x for all EXE/DLL /lib - library numbering, e.g. libpq.dll should be version 3.1, libecpg.dll should be version 4.1 for all DLL /lib/postgresql - release numbering, e.g. 7.5.x for all DLL since these DLLs are used internally by the PostgreSQL server There doesn't seem much point in versioning anything else. To me, it makes more sense to version the libraries such as libpq.dll like their UNIX-based counterparts so the version numberings are consistent between the two. I can see a scenario using release numbering where an application linked to libpq.dll could fail if it checked to ensure the version matched the one it expected, even though an upgrade would not always be necessary if the FE/BE protocol remained unchanged; here the library numbering gives the better indication of the capabilities of the DLL, since any changes in protocol behaviour would be reflected by a change in the major/minor of the version number. Incidentally I've just noticed from my Win32 build a couple of months back that /lib and /lib/postgresql have been combined into /lib. Would this make it more difficult to have different versioning schemes for internal PostgreSQL libraries and the external client libraries as suggested above? Kind regards, Mark. --- Mark Cave-Ayland Webbased Ltd. Tamar Science Park Derriford Plymouth PL6 8BX England Tel: +44 (0)1752 764445 Fax: +44 (0)1752 764446 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
pgsql-patches by date: