Re: [HACKERS] Version numbers (was Re: [PATCHES] Several libpgtcl fixes) - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] Version numbers (was Re: [PATCHES] Several libpgtcl fixes)
Date
Msg-id 199809210325.XAA17970@candle.pha.pa.us
Whole thread Raw
In response to Version numbers (was Re: [PATCHES] Several libpgtcl fixes)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> 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,..."

pgsql/src/tools/RELEASE_CHANGES is the file that shows the changes
required.

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

Not sure how to handle these.

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

pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: [HACKERS] query crashes backend - cvs (fwd)
Next
From: Tatsuo Ishii
Date:
Subject: yet another query to crash the backend