Skip site navigation (1) Skip section navigation (2)

Re: libpq API incompatibility between 7.4 and 8.0

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>,Martin Pitt <mpitt(at)debian(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: libpq API incompatibility between 7.4 and 8.0
Date: 2005-02-02 18:27:49
Message-ID: 200502021827.j12IRn703905@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > We can rectify the mistake, but then we need to change the SONAME.  
> > That's what it's for.
> 
> Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't object.
> 
> This brings up a point that I think has been discussed before: we
> operate on the assumption that incrementing SO_MINOR_VERSION is enough
> to distinguish different releases of libpq, but in point of fact it
> is not.  The Linux conventions for library names, for one, essentially
> require us to bump SO_MAJOR_VERSION for every release if we want to have
> any hope of letting different versions coexist.  Perhaps our convention
> should be to bump SO_MAJOR_VERSION for each of our major releases and
> only use SO_MINOR_VERSION when we change a library in a dot-release.

According to our RELEASE_CHANGES documentation:
	
	The major version number should be updated whenever the source of the
	library changes to make it binary incompatible. Such changes include,
	but are not limited to:
	
	1. Removing a public function or structure (or typedef, enum, ...)
	
	2. Modifying a public functions arguments.
	
	3. Removing a field from a public structure.

so while I don't think we need to update the major number for every
PostgreSQL major release, the removal of prog_name probably required a
major bump.

Oops.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-02-02 18:39:08
Subject: Re: libpq API incompatibility between 7.4 and 8.0
Previous:From: Tom LaneDate: 2005-02-02 18:04:18
Subject: Re: libpq API incompatibility between 7.4 and 8.0

pgsql-patches by date

Next:From: Tom LaneDate: 2005-02-02 18:39:08
Subject: Re: libpq API incompatibility between 7.4 and 8.0
Previous:From: Tom LaneDate: 2005-02-02 18:04:18
Subject: Re: libpq API incompatibility between 7.4 and 8.0

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group