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

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?

regards, tom lane