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

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

On Sun, 20 Sep 1998, Tom Lane wrote:

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

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(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org