> -----Original Message-----
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Magnus Hagander
> Sent: 30 July 2004 09:58
> To: Peter Eisentraut
> Cc: Andrew Dunstan; [EMAIL PROTECTED]
> 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 Cave-Ayland
Webbased Ltd.
Tamar Science Park

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.

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to