Re: Version numbers on libpq.dll

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/

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match