Re: Bumping libpq version number? - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Bumping libpq version number?
Date
Msg-id 20050311181126.GL10437@ns.snowman.net
Whole thread Raw
In response to Bumping libpq version number?  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> Are we still bumping the libpq major version number for 8.0.2?  I think
> it is a bad idea because we will require too many client apps to be
> recompiled, and we have had few problem reports.
>
> We do need to bump the major version number for 8.1 and I am doing that
> now.
>
> One new problem I see is that changes to libpgport could affect client
> apps that call libpq because they pull functions from pgport via libpq.
> For example, now that snprintf is called pg_snprintf, my initdb failed
> in the regression tests because the the new initdb binary used
> pg_snprintf but the installed libpq (ld.so.conf) didn't have it yet.
>
> The bottom line is that we only used to require major libpq version
> bumps when we changed the libpq API.  Now, with libpgport, I am
> concerned that changes in libpgport also will require a major version
> bump.  This adds support to the idea that we will have to do a major
> libpq bump for every major release.

Uh, major libpq version bumps should happen when there's an incompatible
ABI change.  I'm not entirely sure how libpgport relates, but libpq
versions shouldn't be explicitly linked to major release numbers and
it's possible for them to change between major releases...
Stephen

pgsql-hackers by date:

Previous
From: Adrian Nida
Date:
Subject: Re: [ADMIN] PostgreSQL pam ldap document
Next
From: Andrew Sullivan
Date:
Subject: Re: Data loss, vacuum, transaction wrap-around