Re: [gtk-list] Re: 1.1 <=> 1.2 not compatible, why not 2.0?

[Marc van Kempen <marc bowtie nl>]

> > This is not correct, minor version numbers change when the library 
> > remains binary compatible, major version change when the binary
> > compatibility gets broken.
> 
> Irrespective of the technical question (which is fairly easily answered),
> the point that I assume Marc is making here is that it is absolutley vital
> that upgrading gtk does not break existing gtk binaries. He's right - this
> is an total show stopper. Nobody is going to use gtk if they can't be sure
> of that. Just look at the way GTK1.2 has been flamed for breaking 1.0
> binaries.
> 
That is not what I meant.

You cannot always avoid breaking binary compatibility, and gtk+ 1.0 was 
a first release, much has improved since then. However, in order to handle
this binary breakage, the shared library version numbers must be set
accordingly. For gtk+ 1.2 this would mean that it has to have a different 
major version number than gtk+ 1.0!

> > although I must
> > say that if they would have used the major.minor scheme, they would
> > be at version 30.1 by now. Although they also might have chosen to
> > not bother about the version number in the library in the development
> > line.
> 
> He's absolutely right on this one too! Take a look at almost any library.
> The version numbers are pretty small. Announcements like "GTK+68.1 is now
> available" are not going to look good. Frequent loss of binary
> compatibility is a sign of poor understanding of your users and of bad API
> design. People expect to be able to use a function and be sure it's there
> for ever.
> 
You're mixing shared library versions with marketing versions here too.
Look at the example from Steven for XFree86, or more exactly, X11 itself.

These are the libraries for XFree86 3.3.2. The library version numbers have 
nothing to do with the version of XFree86 itself. They are only used,
and should only be used, to indicate binary compatibility from one library
version to the next.
 
lib/libICE.so.6.3
lib/libPEX5.so.6.0
lib/libSM.so.6.0
lib/libX11.so.6.1
lib/libXIE.so.6.0
lib/libXaw.so.6.1
lib/libXext.so.6.3
lib/libXi.so.6.0
lib/libXmu.so.6.0
lib/libXp.so.6.2
lib/libXt.so.6.0
lib/libXtst.so.6.1
lib/liboldX.so.6.0

> I agree that development versions don't matter. There could easily be
> major.even and major.odd with the understanding that new features in
> major.odd might not make it into the next major.even but if they do make it
> into major.even then they are going to stay there. This breaking of
> binaries has to stop dead.
> 
You can't avoid that, gtk+ 1.1.x was a development line, and that's ok
for a development line. Once the development settles down a bit, you'll 
get more stability.

Regards,
Marc.


----------------------------------------------------
Marc van Kempen                 BowTie Technology     
Email: marc@bowtie.nl            WWW & Databases
tel. +31 40 2 43 20 65         
fax. +31 40 2 44 21 86         http://www.bowtie.nl
----------------------------------------------------