Re: Big GDK cleanup

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> > We simply can't go around breaking binary compatibility every 6
> > months, or every year, and I can't see waiting a couple of years for
> > another release. There are a bunch of issues we can and should fix in
> > the short term:
> > 
> >  - Multihead suport
> >  - File selector widget
> >  - Replacement for OPtionMenu and ComboBox
> >  - Action based menu API 
> > 
> > These are all straightforward API additions, and there should
> > be no problem at all doing them in a binary compatible fashion.
> 
> owen, our versioning scheme is designed to:
> 1) introduce a new library name with every MAJOR release to overcome
>    binary/source incompatibilities
> 2) introduce a new library name with every MINOR release to overcome
>    binary/source incompatibilities
> 3) use the libtool .so versioning scheme for MICRO releases, to specify
>    possible breakage in our binary or source interfaces via BINARY and/or
>    INTERFACE age.
> 
> if you think another binary and source compatible release with additional
> API is a worthwhile and reachable goal in say 6-9 months, that can certainly
> be persued, but it'll not be named 2.2 or 3.0 since that changes the .so name.
> so, say we we have released 6 or maybe even 12 updates of 2.0 after those 6-9
> months (i.e. 2.0.6 or 2.0.12), if at that point we want to make another binary
> compatible release with a giant leap in source interfaces, we could do
> something like 2.0.50 (like e.g. gnome-libs in the 1.0.x branch).

That's a nice, logical, view.  Unfortunately, marketing is not
nice and logical. 

 1.0.0  introduced new features
 1.0.x  ... didn't
 1.2.0  introduced new features
 1.2.x  ... didn't
 2.0.0  introduced new features
 2.0.x  ... didn't
 2.0.50 .. did????

While we may think telling about binary compatibility is the best 
use of our version numbers, to the outside world, being
stuck at 2.0.xxx forever several years will look like we
are making progress no and there is no pressing reason to upgrade
to the new versions. (It's the Perl 5.005 syndrome, more or less.)

I know that our version scheme is set up so that it can't naturally
handle binary incompatibility between minor versions. We'll just have
to deal with that with a bit of hackery; confusion for people looking
at the libraries on disk is not as bad as confusion for people looking
at packages, tarballs, and docs.

(Still call our sonames gtk-2.0.so.0.y.z, still install under
gtk-2.0/modules/2.0.x -- essentially pretend we were at 2.0.50, but
make the release 2.2)

Regards,
                                        Owen