On quarta-feira, 23 de outubro de 2013 07:23:22, Alejandro Exojo wrote: > Isn't exactly the same situation as with Qt? When the "next version of Qt > 4.8" breaks binary compatibility, libqt5 is introduced. You link against > either one or the other, and generally, both could be available for you to > choose. > > I'm surprised that libudev0 is not there, though. I suppose all > applications that used libudev0 are ported to the new one.
This is the "source version" number thing we went through with Qt 5.
A library name of type "libname.so.N" contains two versions: the source
version and the binary version. The source version indicates the source
compatibility, the binary one indicates whether there have been any binary
compatibility breaks.
A couple of very explicit examples:
libQt5Core.so.5
libgtk-x11-2.0.so.0
Though extremely unlikely for either of those big libraries to release a
version that breaks BC and keeps SC, it's possible. It's a lot more common in
smaller libraries and we've seen that throughout the years. Examples:
libdbus-1.so.2 and libdbus-1.so.3 (granted, the "1" is the protocol)
libudev.so.0 and libudev.so.1
libpng15
mysql client libraries (which also give us packaging headaches)
libc itself (libc.so.6 is source compatible with libc.so.5)
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
