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

On Sun, 20 Sep 1998, Tom Lane wrote:

> Bruce Momjian <maillist@candle.pha.pa.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 @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org