Re: win32 version info - Mailing list pgsql-patches

From Magnus Hagander
Subject Re: win32 version info
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE34BF74@algol.sollentuna.se
Whole thread Raw
In response to win32 version info  ("Magnus Hagander" <mha@sollentuna.net>)
Responses Re: win32 version info  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-patches
> > 2) We'll *have* to start actually bumping at least minor versions
> > whenever we change the code in a sharaed lib. Which we
> don't do now,
> > except for libpq. For example, plperl still says 0.0, and
> plpgsql says
> > 1.0. Also, all the conversion procs are at 0.0, and they all build
> > from the same rule. That means they all need to get bumped
> when one of
> > them changes. That may be a good idea for unix platforms as
> well, but
> > it is more work during releases that has to be included.
> Not sure if
> > we want to buy into that?
>
> So far we haven't done any versioning on these because
> nothing checks their version.  If you think that now
> something is going to check their versions, then we're going
> to have to do something about that.  But what will happen if
> they stay at 0 indefinitely?

Someone who uses their "corporate standard software distribution tool"
to distribute an upgrade of postgresql will not update these files when
they think they install a new version.

It's better to leave it out completely than to set the version to the
same when the file changes. And only set version on the stuff where we
actually increment the version number.

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.


//Magnus

pgsql-patches by date:

Previous
From: Devrim GUNDUZ
Date:
Subject: Updated Turkish FAQ
Next
From: Bruce Momjian
Date:
Subject: Re: pg_ctl -o option dumps core when processing postmaster arguments...