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