Re: Version numbers on libpq.dll

Are you saying this line has to be updated in libpq/libpq.rc?

FILEVERSION 8,0,0,0

and the final zero needs to be incremented, and all the other mentions
of 8,0,0,0 in that file?

We do have the checklist to update this for every major and minor
release. What we _don't_ do is to update those from beta/RC to final.
The only change between those two versions is that we update the version
string in configure.in so "SELECT version()" and documentation show the
proper value. This is because the libraries are always installed and
applications linking against those libraries don't need any change
between the beta and the final. I wonder if the proper change is to
have the installer always install the library and throw an error if it
fails. Is that possible?

---------------------------------------------------------------------------

Magnus Hagander wrote:
> Hi!
>
> We have a problem with the version numbers on libpq.dll. We have been
> shipping the DLL through all betas and the RC with version number
> "8.0.0.0". This has already caused several error reports both on the
> mailinglists and on the pgFoundry bug trackers, because the file is not
> replaced if you install two versions in parallell. Or if the file is in
> use when installing a newer version. The installer will correctly check
> the version number and determine that the file has not been updated.
>
> In order for installation to work correctly, everytime there is a change
> to the DLL the version number has to increase. Now, we certainly don't
> need to bother with that between releases, but once a release (IMHO,
> *including* beta or rc releases) it has to be bumped. We expecially need
> it bumped when we go to release, otherwise people *will* end up running
> their 8.0 release servers with pre-release libpq.dll.
>
> Each of the numbers in the version number is a 16 bit integer. We are
> already using the first three for the "normal" version number
> (8.0.0/8.0.1 etc). The easiest way would be to simply have the fourth
> number bumped up by one every time a new release is tagged. It can be
> reset to zero whenever the file is changed into a new version (when the
> first three change).
>
> Could this be added to the "release tagging/building" checklist?
> (affected file is src/interfaces/libpq/libpq.rc, several locations in
> the file)
>
> Another option would be to generate this automatically at build time.
> Not sure how to do that really - I've been using subversion repository
> versions there in some other projects, but since there is not a single
> file building the DLL we can't do that with cvs, right? It might also
> give some very interesting (heh) results in different branches etc.
>
> Note! This is *only* necessary for libpq.dll, since that's the only one
> we drop in SYSTEM32. The others can live side-by-side. It would be nice
> to have the increasing between all releases just to be sure, but not at
> all as important.
>
> Hoping to get this in before 8.0.0, since it's not an actual code
> change, and we *will* get a lot of bug reports if we don't get it fixed.
>
> //Magnus
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>

--
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