Re: GNOME Namespace Management - ARC & GNOME



On Thu, 2004-12-16 at 01:36 +0000, Sander Vesik wrote:

> > What I've been trying to figure out is how far Suns
> > commitment extends: take the example of GObject construct only properties.
> > Would ARC have let this change through, if glib was written by
> > Sun?
> > 
> 
> Provided I'm not confusing the change with some other - it would have cause glib
> library major bump so instead of libglib-2.0.so.0 there would now also be
> libglib-2.0.so.1 with the .0 version being available for a long time. And this is
> not even close to somehow Sun sopecific - you change ABI, you bump the shlib version
> so 
> that you can parallel install for applications that need it. 

I'm getting annoyed with this example; let me emphasize that there are
really objects out there that fall apart all over the place if you
change construct-only arguments after construction. The fact that 
a check for G_PARAM_CONSTRUCT_ONLY had been missed was serious bug.

Complete bug compatibility means that you don't change anything ever
with the same soname. Users end up with a mix of GTK+-2.0, 2.2, 2.4, 2.6
apps on their system, each which have slightly different menu behaviors.
The GTK+-2.0 app doesn't have antialiased fonts. Certain strings
misrender in some of the apps because they are using older versions of
Pango. 

Let's not mention the fact that that you need to bump the soname
of every other library that depends upon GLib when you bump the soname
of GLib. We've had enough problems with apps that end up linking
to both glib-1.2 and glib-2.0. Starting bumping the soname within
the 2.x series...

Bumping the soname is simply not even worth considering. The only
possible solution would have to been not to fix the bug. Realistically,
backwards compatibility is never black-or-white. What fixes one app
breaks another. When we become aware of a backwards compatibility issue
caused by a bug fix or feature addition, we consider a range of factors:

 - Can we work around the breakage without losing functionality?

 - Where is the breakage? ... if the breakage is in a component
   distributed with GNOME, that's more manageable than a 3rd party
   app. If the breakage is in an unreleased CVS version of Emacs, we
   probably don't care.

 - How crazy is the thing that the app is doing. People have been
   known to access GTK+ internal structures, hunt in the 
   internal descendants of a composite widget, etc. To avoid 
   paralysis, you have to be willing to take the "you should have
   known better" stance in some case.

 - Have we already released with the breakage? - if GTK+-2.2.0 
   breaks compat for some app, you aren't going to help the app
   author that much by releasing GTK+-2.2.1 that reverts the
   change. (The change, if it was needed to introduce API, may not be 
   revertable post release...)

   Yes, it would be nice to always know about problems before we
   release... but testing every single app that uses GTK+ is a
   logical impossibility. So some things will slip through.

And then make our best call. 

The more people use GTK+, the harder it is to make changes. At
some point, GTK+ will be in the land of Motif where any feature
addition is going to cause more problems than it helps. Where any
change in the behavior of any app is a severity 1 bug. I'm glad
we aren't there yet.

Regards,
							Owen

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]