Thread: Shared library version

Shared library version

From
"Oliver Elphick"
Date:
There appear to have been changes in the shared library libpq.

The default library from 6.5.3 with psql from current tree gives:
 olly@linda$ psql template1 ... psql: error in loading shared libraries: psql: undefined symbol:   
createPQExpBuffer
 olly@linda$ LD_PRELOAD=/usr/local/pgsql/lib/libpq.so.2.0 psql template1 ... template1=>

Since the library has changed, it needs to have a new version number.

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver              PGP key from public servers; key
ID32B8FAA1                ========================================    "Be patient therefore, brethren, unto the coming
ofthe     Lord...Be patient; strengthen your hearts, for      the coming of the Lord draweth nigh."
                       James 5:7,8 
 




Re: [HACKERS] Shared library version

From
Bruce Momjian
Date:
> There appear to have been changes in the shared library libpq.
> 
> The default library from 6.5.3 with psql from current tree gives:
> 
>   olly@linda$ psql template1
>   ...
>   psql: error in loading shared libraries: psql: undefined symbol:   
> createPQExpBuffer
> 
>   olly@linda$ LD_PRELOAD=/usr/local/pgsql/lib/libpq.so.2.0 psql template1
>   ...
>   template1=>
> 
> Since the library has changed, it needs to have a new version number.

Seems I should just kick up every minor version number for 7.0 for all
interfaces.  OK?

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: [HACKERS] Shared library version

From
Tom Lane
Date:
"Oliver Elphick" <olly@lfix.co.uk> writes:
> There appear to have been changes in the shared library libpq.
> Since the library has changed, it needs to have a new version number.

You're right, we need to bump the number before release (and I hope we
remember!).  Past practice has not been to bump the number during
development cycles, since we'd shortly have ridiculously high version
numbers if we incremented them at every development change.

libpq++ has also had API changes requiring a new version number before
release, I think --- any others?
        regards, tom lane


Re: [HACKERS] Shared library version

From
Michael Meskes
Date:
On Mon, Jan 10, 2000 at 10:22:44AM -0500, Tom Lane wrote:
> You're right, we need to bump the number before release (and I hope we
> remember!).  Past practice has not been to bump the number during
> development cycles, since we'd shortly have ridiculously high version
> numbers if we incremented them at every development change.

Ehem... I do exactly that with libecpg. For simply changes not involving API
changes I increment just the patch level. That's why libecpg has major
version, minor version and patchlevel. 

I find it very difficult to keep track of the changes without changing
version number.

So please, do not change this number upon release.

Michael
-- 
Michael Meskes                         | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz    | Go Rhein Fire!
Tel.: (+49) 2431/72651                 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De           | Use PostgreSQL!


Re: [HACKERS] Shared library version

From
"Oliver Elphick"
Date:
Tom Lane wrote: >"Oliver Elphick" <olly@lfix.co.uk> writes: >> There appear to have been changes in the shared library
libpq.>> Since the library has changed, it needs to have a new version number. > >You're right, we need to bump the
numberbefore release (and I hope we >remember!).  Past practice has not been to bump the number during >development
cycles,since we'd shortly have ridiculously high version >numbers if we incremented them at every development change.
 

Yes, but it should be bumped the first time it changes; I agree that it 
need not be increased during later development of the same release.

A patch would be superfluous.  The necessary change is simply to
increment SO_MINOR_VERSION in src/interfaces/libpq/Makefile

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver              PGP key from public servers; key
ID32B8FAA1                ========================================    "Enter into his gates with thanksgiving, and into
his     courts with praise. Be thankful unto him, and bless      his name."           Psalms 100:4 
 




Re: [HACKERS] Shared library version

From
Peter Eisentraut
Date:
On 2000-01-10, Tom Lane mentioned:

> "Oliver Elphick" <olly@lfix.co.uk> writes:
> > There appear to have been changes in the shared library libpq.
> > Since the library has changed, it needs to have a new version number.
> 
> You're right, we need to bump the number before release (and I hope we
> remember!).  Past practice has not been to bump the number during
> development cycles, since we'd shortly have ridiculously high version
> numbers if we incremented them at every development change.
> 
> libpq++ has also had API changes requiring a new version number before
> release, I think --- any others?

It would at least be fair to bump the minor version number when you do the
branch for a new version, so now we'd be at 2.1. IIRC the dynamic linker
will pick the one with the higher minor version. Since we do not have any
incompatible changes (?) we shouldn't bump the major version.

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden




Re: [HACKERS] Shared library version

From
Vince Vielhaber
Date:
On Tue, 11 Jan 2000, Peter Eisentraut wrote:

> On 2000-01-10, Tom Lane mentioned:
> 
> > "Oliver Elphick" <olly@lfix.co.uk> writes:
> > > There appear to have been changes in the shared library libpq.
> > > Since the library has changed, it needs to have a new version number.
> > 
> > You're right, we need to bump the number before release (and I hope we
> > remember!).  Past practice has not been to bump the number during
> > development cycles, since we'd shortly have ridiculously high version
> > numbers if we incremented them at every development change.
> > 
> > libpq++ has also had API changes requiring a new version number before
> > release, I think --- any others?
> 
> It would at least be fair to bump the minor version number when you do the
> branch for a new version, so now we'd be at 2.1. IIRC the dynamic linker
> will pick the one with the higher minor version. Since we do not have any
> incompatible changes (?) we shouldn't bump the major version.

libpq++ got a major number bump on my first sweep.  This time through 
it should only need a minor since I don't forsee any operational changes,
just additional functionality and bug fixes.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net  128K ISDN: $24.95/mo or less - 56K Dialup:
$17.95/moor less at Pop4       Online Campground Directory    http://www.camping-usa.com      Online Giftshop
Superstore   http://www.cloudninegifts.com
 
==========================================================================