Chris Frey wrote:
> I find it confusing that the major version of the library is 4,
There's precedent. The MySQL C API library I use is version 12, for
> doesn't tell the administrator anything useful.
Under RPM, you can say 'rpm -qf /usr/lib/libmysqlpp.so.4' and get
'mysql++-1.7.31' back. Other package systems I've used have a way to
ask what package owns a particular file, too.
> Multiple versions at once is an administration feature, and would make
> a lot of sense when 1.8, 1.9, etc are released so that stable and dev
> versions could be run at the same time.
I'm uncomfortable going backwards in version numbers at this point. If
versions 4 and 1.8 are installed, g++ will try to link against version 4
when building the binary.
In any case, I'm not really asking about having both 1.8 vs. 1.9
libraries installed. Presumably there's an ABI change between those
two, so under the current scheme they'd get different library names, so
you could still install the new one without needing to relink old binaries.
Ignoring the v4 vs. v1.x issue, what I'm really asking is, is there any
point in having both libmysqlpp.so.1.7.31 and libmysqlpp.so.1.7.32
installed? That's the situation that causes overhead for each release,
and which has no value unless you make the effort to link against a
specific point release. I can make libtool use these version numbers,
but unless a program is linked specifically to one point release,
there's little point in making the effort.
> It's all just symlinks anyway:
Yes, but those symlinks are maintained by ldconfig on a Linux system. I
have no control over them. I could make my own symlinks, but then I'm
fighting the system.
> Perhaps a jump in version to an even number for the next stable release
> would make things look more like the kernel. :-)
...except that they just abandoned the whole even/odd thing. :)