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

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Version numbers (was Re: [PATCHES] Several libpgtcl fixes)
Date: 1998-09-21 03:25:43
Message-ID: 199809210325.XAA17970@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

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(at)candle(dot)pha(dot)pa(dot)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. |

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 1998-09-21 03:31:53 yet another query to crash the backend
Previous Message Oleg Bartunov 1998-09-21 02:33:17 Re: [HACKERS] query crashes backend - cvs (fwd)