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

Re: [HACKERS] Version numbers (was Re: [PATCHES] Several libpgtcl fixes)

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Version numbers (was Re: [PATCHES] Several libpgtcl fixes)
Date: 1998-09-21 06:04:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sun, 20 Sep 1998, Tom Lane wrote:

> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> BTW, I bumped the package version number from 1.2 to 1.3.  Is this
> >> premature?  Does someone run around and do that routinely before
> >> each pgsql release?
> > What verison numbers?  I didn't know we had any version numbers excepct
> > PG_VERSION, and I update that one
> There are version numbers all over the place in the various frontend
> libraries.  The particular one I was speaking of was libpgtcl's number
> as seen by the Tcl "package require" command.  However, we also need
> a strategy for dealing with the shared library version numbering of
> libpq, libpgtcl, and anything else that is compilable as a shared lib
> (is libpq++?).  I think that the perl5 interface also has some kind of
> version number that's seen by Perl's package version control.
> Making all these numbers match PG_VERSION would probably be a loser,
> because they generally have semantics of their own: a shlib major
> version number indicates whether you can expect to use it with an
> existing application without relinking, for example.  You want to bump
> a shlib's version number when its API changes, not when the backend
> changes.  Therefore, each one of these libraries requires individual
> attention to the version number :-(
> I think that it would be a good idea to have as part of the standard
> pre-release checklist (there is one, no?) an item "what should we do
> to the version numbers of libraries a,b,c,d,..."
> While we're on the subject, I was going to propose bumping the shlib
> version number of libpq itself from 1.0 to 2.0 for this release,
> because (a) I don't think it's entirely binary compatible with the
> previous libpq release (depends on whether people were touching the
> PGconn struct directly...) and (b) people might want to keep around both
> libpq 1.0 and 2.0 to talk to backends of different vintages.  I'm not
> sure whether any of the other frontend libs need a major version bump.
> Comments?

	I have a c) ... wouldn't up'ng the shlib major/minor numbers at
release time serve to eliminate that "bug" about 'Heap tuple is not \9'
(or however that error went?)...?

Marc G. Fournier                                
Systems Administrator @ 
primary: scrappy(at)hub(dot)org           secondary: scrappy(at){freebsd|postgresql}.org 

In response to

pgsql-hackers by date

Next:From: Oleg BartunovDate: 1998-09-21 06:34:53
Subject: Re: [ Re: [HACKERS] BUG: NOT boolfield kills backend]
Previous:From: The Hermit HackerDate: 1998-09-21 06:02:16
Subject: Re: [HACKERS] Transaction system (proposal for 6.5)

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