> > 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.
pgsql-patches by date
|Next:||From: Bruce Momjian||Date: 2004-07-29 16:10:09|
|Subject: Re: pg_ctl -o option dumps core when processing postmaster arguments...|
|Previous:||From: Devrim GUNDUZ||Date: 2004-07-29 15:04:31|
|Subject: Updated Turkish FAQ |