Version numbers on libpq.dll

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

Magnus Hagander said:

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

Why is it put in SYSTEM32? My understanding is that that's considered less
than polite in the Windows world. (Buildfarm copies libpq.dll to
<install>/bin for both Cygwin and Windows, which seems to work just fine for
me).

cheers

andrew

Magnus Hagander schrieb:
> 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.

I strongly backup this claim. Really, the forth number is always the
build number and should never be dropped to 0 again.

At least I never saw it dropped in several other projects which lasted
for decades, with regular weekly builds and daily in the last weeks
before release.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

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