Bumping libpq version number? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Bumping libpq version number?
Date
Msg-id 200503111758.j2BHwSE10414@candle.pha.pa.us
Whole thread Raw
Responses Re: Bumping libpq version number?  (Stephen Frost <sfrost@snowman.net>)
Re: Bumping libpq version number?  (Peter Eisentraut <peter_e@gmx.net>)
Re: Bumping libpq version number?  (Kurt Roeckx <kurt@roeckx.be>)
List pgsql-hackers
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.

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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [pgsql-hackers-win32] snprintf causes regression
Next
From: Adrian Nida
Date:
Subject: Re: [ADMIN] PostgreSQL pam ldap document