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