Re: Big GDK cleanup

[Tim Janik <timj gtk org>]

On 8 Sep 2001, Owen Taylor wrote:

> To quote my Changes-2.0.txt entry:

[...]

thanks for the detailed wrapup.

> > > Which I think represents a significant improvement in cleanly defining
> > > our interfaces and making sure that we can maintain binary compatibility
> > > in the future. (Removing the exported structures is even more important
> > > for this purpose.)
> > 
> > hum, what huge binary incompat changes are you pondering about for 2.0.x?
> > or did you mean "source compatibility" for 2.x?
> 
> While I don't want to get into a big 2.2 discussion here, I 
> believe it is _strongly_ in our interests to do a source
> compat feature addition release in a short (hopefully 6-9 month) 
> timescale. Such a release needs to also be binary compatible:

[...]

> 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).

> 
> Regards,
>                                         Owen
>  

---
ciaoTJ