>> Well, because it allows the user as well as other programs to
>> identify what version of a file is installed.
>
>psql --version
That works for an executable. And that works for the user. Doesn't work
as well for a piece of software that does this. How is it supposed to
know which .EXEs it can send "--version" to? And it won't work for any
DLLs.
>> For error-checking
>> purposes (which DLL version is really there? And debugger will also
>> tell you which version of the DLL is actually loaded in the process
>> working space if yo uhave more than one on your system),
>
>OK, that should go into the DLL, just as it goes into shared libraries
>on Unix. But then you need to use the actual shared library versions
>that we use.
Um. Right. That goes on some things (like libpq). But all DLLs don't
have that (seems plpgsql still claims 1.0, which can hardly be correct,
for example. There has to have been *some* revisions to it since it was
created...). But perhaps that should be fixed in the general shared lib
version, then?
The common way to do it on win32, if we want to follow that, is to have
<majorversion>.<minorversion>.<build>.<sub-build>. Mapping that to the
shlib would be more along the line of 7.5.<shlibmajor>.<shlibminor>. If
we want to go down that path.
>> software
>> distribution (all installers are required to check this field to make
>> sure they don't overwrite a file with an older version), software
>> inventory, the list goes on.
>
>This is the packager's business, not ours.
It's our business to make it *possible* for the packager, IMHO. And by
not including version information, we make it impossible for someone to
use the unpatched source tree to make a compliant installer for
postgresql.
And putting the responsibility on the packager still doesn't help for
the inventory case.
//Magnus
