Re: Getting to 8.3 beta1

* Heikki Linnakangas (heikki(at)enterprisedb(dot)com) wrote:
> Tom Lane wrote:
> > * Do we bump the .so major version number for libpq? I think we should
> > because there are two new exported functions since 8.2, and on at least
> > some platforms there's nothing else than major number to disambiguate
> > whether a client needs these or not. Comments?
>
> I'm not very familiar with library versioning, but the modern solution
> is to use symbol versioning. In that scheme, a backwards-compatible
> change, like adding new functions, requires a bump of the minor version
> number only. I believe all major modern platforms supports symbol
> versioning.

You're kind of half-right... The 'modern' solution is symbol
versioning, but it's certainly not required. A backwards-compatible
change is usually a minor revision bump so that utilities which use the
new functions know that they need a more recent version to use it, while
old utilities can continue to use the interfaces in place. It should
*not* change the soname. Systems do not need symbol versioning support
to handle this properly. Stictly speaking, you don't have to change
anything.

The new library will work for old binaries, that's the primary concern
and if functions are only added there's no problem. If you're concerned
about new binaries with an old library then bump the minor version. It
won't stop them from attempting to link but it's a signal to packagers
to update their dependencies accordingly.

Few projects have moved to symbol versioning, unfortunately. glibc is
the big user of it and they do a good job of it in general. This allows
in-place upgrades of glibc and supporting multiple versions of glibc
symbols being exported at once. It also means that multiple glibc's can
be linked in to a running binary at once.

Bumping the soname is an indication of a binary-incompatible change and
means that old binaries *can't* link against the new library, and so
everything has to be recompiled. Please don't do that unless it really
is a binary-incompatible change because it's alot of extra work for
packagers to deal with all of their reverse dependencies and getting
everyone to recompile.

Thanks,

Stephen