* Heikki Linnakangas ([EMAIL PROTECTED]) 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
Description: Digital signature