[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] .so version number question



On IRC, Chris raised the question on what version number we should be
using for libvirt.so.  The libtool manual has an entire chapter on the
matter:
http://www.gnu.org/software/libtool/manual/libtool.html#Release-numbers

In particular, it states that if you are using the -version-info flag to
libtool (which our src/Makefile.am currently does), then you are
promising to abide by the libtool versioning rules, where the .so
version is treated as current:revision:age (and not major.minor.micro).
 In fact, libtool goes so far as to state that "Never try to set the
interface numbers so that they correspond to the release number of your
package. This is an abuse that only fosters misunderstanding of the
purpose of library versions. Instead, use the -release flag (see Release
numbers), but be warned that every release of your package will not be
binary compatible with any other release."

Should we be using -release instead of -version-info?  Or should we
continue using -version-info, but follow the advice of divorcing the .so
version number from the release number?

For example, according to the libtool rules, if the two version numbers
are independent, then going from libtool 0.7.7 to 0.8.0 (that is, a
minor version number bump in terms of packaging numbering), should go
from libvirt.so.0:7:7 (we are at API version 0, with seven revisions of
the code implementing that API, and are compatible back to -7:0:0, which
is nonsense, so it effectively works out that we are compatible back to
0:0:0) to libvirt.so.1:0:1 (we added API, this is the first
implementation of that new API, and we are compatible back to 0.x.x).
Going by the libtool rules means that the c.r.a field will increment 'c'
rather frequently (basically, every time we add an API!), but as long as
'a' increments just as frequently, then we are not making any backwards
incompatible changes.

But if you don't like that, the we should be going by the -release flag
to libtool, where the .so numbering matches the libvirt release
numbering.  On the other hand, libtool states that using the -release
flag means that anyone that uses libtool to link against libvirt.so is
treated as being an incompatible change (basically, even though we are
striving hard to maintain backwards compatibility, libtool can't exploit
that).  Again from the manual, "Note that this option causes a
modification of the library name, so do not use it unless you want to
break binary compatibility with any past library releases. In general,
you should only use -release for package-internal libraries or for ones
whose interfaces change very frequently."  Libvirt's interface changes
frequently, but libvirt.so is not a package-internal library so I don't
think that -release is the way to go.

Should I try to prepare a patch to start making better use of the
-version-info libtool flag according to the libtool rules?  And if so,
is everyone okay with just punting on this issue until after 0.8.0 is
out the door?

-- 
Eric Blake   eblake redhat com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]