Sven Neumann <sven@xxxxxxxx> writes:
> We do follow the standard library version numbering. The problem is
> that either you did not understand it or didn't look close enough.
> Let's have a look at configure.in:
standard libray versioning scheme is to set soname to
lib<name>.<major> (library being named lib<name>.<major>.<minor> on
filesystem)
you confuse library version number and library major.
you do not have to put version number in soname.
some examples:
--------------
arts1-1.1.94 major is 2 for libkmedia
aspell-0.50.3 major is 15
freetype-2.1.4 major is 6
gal-0.24 major is 23
gcc-3.3.1 major are 1 for libgcc and 5 for libstdc++
gmp-4.1.2 major is 3
gnome-libs-1.4.2 major are 32 for libgnome and 1 for gtkxmhtml
gnomeprint-0.37 major is 15
gnomespeech-0.2.8 major is 6
gtkspell-2.0.3 major is 0
kde3.2 majors are 0 for kdegraphics, 1 for kdeaddons, kdeadmins,
kdetoys, kdesdk, kdeedu, kdeutils and kdemultimedia,
2 for kdenetwork, kdepim, 3 for kdedevelop, 4 for
kdebase, ...
krb5 majors are 2 for krb4 and 3 for krb5
libmpeg-1.5 major is 3
mozilla-1.5 major is 4 libnspr and 3 for libnss
ntfsprogs-1.7.1 major is 4
png lib 1.2.5 major is 3
raw1394-0.9.0 major is 5
vorbis-1.0 majors are 0 for main vorbis lib, 2 for vorbisenc, 3 for vorbisfile
(...)
> The libraries have the binary version in their names because they
> are different. libgimp-1.2 and libgimp-2.0 are different libraries
> and by no means compatible.
the same way newers version of libal are binary incompatible with
previous ones because of api additions, changes, ... (or any toolkit
because of new/obsolete widgets).
the same is very true for every other project out that properly bump
its library major instead of hardcoding the library version name in
its soname (which is dumb when a new version is binary and source
compatible with the previous ones - at least gimp does not hardcode
its minor version number in its soname)
if the a branch of a library is not compatible with the previous one,
maintainer only has to bump its major.
nothing more.
> They are supposed to coexist so they need the binary version in the
> library name.
different versions of the same library coexists because they've
different majors.
this is how different versions of gal coexists
> The library version is then created from the version information as
> given above. During a development cycle, each release is
> incompatible to the previous, so interface age and binary age are
> always set to 0. When 2.0.0 is out, we will apply the rules as given
> above. This is certainly a very much standardized way of handling
> library versions and I can you give you a very long list of projects
> that do it this way.
and i can also give you a very long list of projects that do it the
other way.
