Re: GNOME Namespace Management - ARC & GNOME

[Sean Middleditch <elanthis awesomeplay com>]

On Wed, 2004-12-15 at 15:26 -0600, Brian Cameron wrote:
> ARC would let such a change go through if the team responsible for GObject
> dealt with the change in a manner that supports users of the interface.
> ARC would want the team responsible for GObject to ensure that it made
> reasonable efforts to identify what programs would be affected and to
> work with them to ensure that any user upgrading GObject also upgrades
> any affected programs at the same time.

That's not good enough.  Users are not going to just upgrade
applications.  How would they know?  Why should they _have_ to know?  If
they install Linux Weekly Distro V56, then install FooApp, then upgrade
to Linux Weekly Distro V57, FooApp should not break.

No application should need to be upgraded because a library changed.  If
the library breaks ABI, fine, install a new version.  There is no cosmic
law that states that the library interface version of a library in GNOME
2.10 has to be 2:10.  It is perfectly allowed to be 40:97, if the binary
interface breaks that often.  Calling something 2:10 when you know it
breaks anything depending on 2:8, or even 2:0:0, is a lie, and is
breaking applications needlessly.

It's not even necessarily feasible for an application to change.  FooApp
is written for GTK 2.4.  It breaks on GTK 2.6.  FooApp hasn't been
maintained in over a year.  Is it to become the community's
responsibility to fix FooApp?  The users'?  The glib maintainers'?  It
wouldn't even be an issue if the library just didn't break
compatibility, right?  Which option makes more sense - break tons of
apps and have to fix all that code due to one library upgrade, or just
not break them?

> If such a change caused a user program to break, then Sun would have to
> figure out how to appropriately patch the system to keep things working
> for that user.  Keeping multiple versions of a library on a system, for
> example, might be an approach that would be used to support such users.
> 
> The point of interface stability in Sun is not to prevent change, but
> to ensure change happens in a controlled fashion.

The hard part for most Open Source/Free Software developers is
understanding just what that sentence means.  I so very often have
people tell me, "binary compatibility is pointless to even try for on
GNU/Linux!  it's the nature of Open Source to be ever changing and ever
improving!"  People don't seem to understand that you can _improve_
without breaking stuff and that you can make _changes_ without make
_breakages_.  You just have to make the changes right.

gtk/glib breaking compatibility and not bumping the major version number
is, beyond any doubt, *not* the right way to make the changes.  Please,
if we add more more formality and bureaucracies to the development
process, make sure that they actually fix the problem - any breakage,
any breakage at all, is unnecessary and defeats any and all other
efforts to avoid the breakages.

Either keep 100% compatibility or just bump the library interface major
version appropriately.  Thanks.

> 
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.