Re: Version numbers on libpq.dll

> > >> The idea that someone is going to update that version
> string every
> > >> time there is a change to libpq isn't going to happen
> reliably if at all.
> > >> Maybe that value should be set by the installer to be
> the number of
> > >> days since 1970.
> >
> > > We could set it when building the installer by hacking up the DLL
> > > file, but that's really ugly, because then there would be no
> > > correlation with the official version numbers. And we
> claim to ship
> > > the official version...
> >
> > Also, that approach won't work *at all* for people who build from
> > source without using the installer. I think it would be a real bad
> > idea for the installer to install something different than
> what you'd
> > get from a hand build of the identical source release.
> >
> > I think we have to bite the bullet and include "bump low
> part of DLL
> > version number" as part of the standard release checklist.
> This will
> > at least solve the problem for people who use official
> tarballs. Them
> > as build from CVS pulls are going to have to guard against
> the problem
> > for themselves, but it's not like there haven't always been
> equivalent
> > gotchas on the Unix side.
>
> It is more complicated than that. First, people building
> from CVS will just install everything in /bin and /lib and
> put nothing in SYSTEM32.

Yes.

> You have to add the /lib to your %PATH% for anything to work,
> or copy the DLL into /bin.

Correct. And doing so will *override* the one in SYSTEM32. I use the
copy-to-bin myself all the time since that makes sure there is NO WAY
I'm working off a wrong libpq. The downside is that I have to make one
copy for psql, one for pgadmin, one for <test program a>, one for <test
program b> etc.

> Second, if two installers are created during beta2, they are
> going to have the same version numbers and will not be
> updated, so a fix to libpq will not get propogated. I see no
> way to manage that except having the installer do it.

Like I've said repeatedly, we do not plan to put out installers with
in-between-beta builds. We've done so in the past for some reasons, but
now that both pg for win32 and the installer is more mature, we're not
going to do that. And if we are required to do that for some reason at
some point, I'm sure we can bribe someone to bump the version number
between betas as well. Since that is definitly an *exception*, and not
the rule.

I don't think this is an issue.

> The libpq.dll in SYSTEM32 and /lib will be different in that
> SYSTEM32 will have the updated version stamp, but it is my
> understanding only the installer cares about those version
> numbers, so that seems OK.

Not sure that I follow this part completely. If you build from cvs and
follow the default stuff, you will have the libs for the cvs version in
that versions local directories and those apps are not affected by
what's in SYSTEM32 (assuming you copy it from lib to bin, which you will
probably know to do if you're building off cvs. We are trying to solve
the problem for the "big masses", not for the developers. Developers
will probably not use the installer)

I agree very much with Toms comment about the fact that the installer
project should *NOT* modify the files unless absolutely unavoidable.

//Magnus

Magnus Hagander wrote:
> > It is more complicated than that. First, people building
> > from CVS will just install everything in /bin and /lib and
> > put nothing in SYSTEM32.
>
> Yes.
>
> > You have to add the /lib to your %PATH% for anything to work,
> > or copy the DLL into /bin.
>
> Correct. And doing so will *override* the one in SYSTEM32. I use the
> copy-to-bin myself all the time since that makes sure there is NO WAY
> I'm working off a wrong libpq. The downside is that I have to make one
> copy for psql, one for pgadmin, one for <test program a>, one for <test
> program b> etc.

True.

> > Second, if two installers are created during beta2, they are
> > going to have the same version numbers and will not be
> > updated, so a fix to libpq will not get propogated. I see no
> > way to manage that except having the installer do it.
>
> Like I've said repeatedly, we do not plan to put out installers with
> in-between-beta builds. We've done so in the past for some reasons, but
> now that both pg for win32 and the installer is more mature, we're not
> going to do that. And if we are required to do that for some reason at
> some point, I'm sure we can bribe someone to bump the version number
> between betas as well. Since that is definitly an *exception*, and not
> the rule.
>
> I don't think this is an issue.

I question whether any of us will remember to modify libpq.rc if you
happen to be making a new installer twice in the same beta. As a group
we forget even simpler things regularly. And we would be adding an
additional change for each beta and each RC for only the installer. I
am not inclined to add more work to a process that already is pretty
complex.

However, that is Marc's roll and he can answer whether he can do it
reliably. I am not involved in that process.

> > The libpq.dll in SYSTEM32 and /lib will be different in that
> > SYSTEM32 will have the updated version stamp, but it is my
> > understanding only the installer cares about those version
> > numbers, so that seems OK.
>
> Not sure that I follow this part completely. If you build from cvs and
> follow the default stuff, you will have the libs for the cvs version in
> that versions local directories and those apps are not affected by
> what's in SYSTEM32 (assuming you copy it from lib to bin, which you will
> probably know to do if you're building off cvs. We are trying to solve
> the problem for the "big masses", not for the developers. Developers
> will probably not use the installer)

My point is that installing from CVS will always overwrite libpq.dll in
/lib, so it doesn't care what the version stamp is in the binary. Only
the installer cares about the internal version stamp.

> I agree very much with Toms comment about the fact that the installer
> project should *NOT* modify the files unless absolutely unavoidable.

Only the installer cares about the version stamp so the most reliable,
clearest place to set that value is in the installer build.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073