Lamar Owen wrote:
> On Friday 20 May 2005 09:43, Dave Cramer wrote:
> > Lamar Owen wrote:
> > >On Friday 20 May 2005 07:55, Dave Cramer wrote:
> > >>Well, there's not much discussion here. Other than the fact that a few
> > >>things depend on libpq.so.3.
> > >>Isn't the standard to keep libpq.so.(n-1) whenever you bump the number up
> > >> ?
>
> > >Only because libpq versioning has always been an afterthought in the
> > > upstream release process.
>
> > OK, so how do we fix this ?
>
> Any time a change is made to libpq that changes its exported symbols or ABI a
> version change needs to be made. The person committing the change that
> impacts the ABI needs to be the person responsible for changing the version
> number; otherwise someone needs to monitor libpq changes coming down
> committers and remind people when they need to bump the libpq major or minor
> so version. Further, any time a release is being built one of the top things
> on the checklist should be 'is libpq's soname appropriate or not?'
What hit us in this case is the movement of a function (get_progname())
from libpq to pgport and now that certain binary applications were
pulling get_progname from libpq rather than pgport. So the API didn't
really change, just the place applications looked for symbols.
What also hit us is that people complaining about this during beta
testing were told just to recompile (which fixed it), but we didn't
realize that it prevented installs of 7.4 from working.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073