Re: Proposed Modules, My Take

[Mike Hearn <mike navi cx>]

On Thu, 2005-01-20 at 09:19 +0100, Murray Cumming wrote:
> This is your own definition of ABI stability.

It's the industry standard definition used by Microsoft, Sun, Apple and
indeed GNOME. 

> Our current definition is roughly "applications will not _stop_ working
> when a new version of the dependency is installed".

That's the definition used by the GNOME bindings release but not by
GNOME itself. It ignores the fact that stability isn't just about things
not breaking, it's also about efficiency, bugfixes etc.

> Your definition would be nice, but I see no point in demanding it while
> it is unattainable. I do see the point in encouraging what is currently
> possible.

Why is it unattainable? Alright, Python is in a bad state and Java is
only really ABI stable if you use a Sun JVM or a clone (ie not gcj), but
C++ will hopefully stabilise soon. Or at least I'd be very disappointed
if the GCC team broke compatibility *again*.

> > What I'm saying is I'm not sure what the point of the bindings release is,
> > as you can't depend on it as a developer. I guess it's useful to collect
> > them all together and sync their release schedules.
> 
> You are ignoring the existence of distro package management, probably
> because you wish that it wasn't necessary. The Bindings release helps
> developers in the current real world.

I disagree. You can't say "distros will sort that out", otherwise why
bother having a GNOME developer platform at all? You might as well say
that every GNOME release could be totally different as long as it was
parallel installable, which is totally not the point of parallel
installability. Clearly that'd be crazy:

- GNOME is quite big, you don't really want 8 copies of it in memory at
  once.

- Developers don't like constantly rewriting their apps to use new APIs,
  eg while s/alterProperty()/setProperty()/ may make a Java API more
  consistent for newcomers it just annoys people who already wrote their
  code and now have to go through and change it.

- Old interfaces stick around for ages. There are still a significant
  number of GTK+ 1 based apps in everyday usage.

Just saying that it's not GNOMEs problem and distros should sort it out
has another weakness: ISVs who want to distribute their own binaries
don't use distro package management. Ever. That includes *all*
proprietary ISVs. It also includes third party open source projects who
aren't big enough to be widely packaged, or projects (like Wine) which
are but provide their own binaries because downstream screw it up so
often.

It was a policy decision made a long time ago that GNOME should be
usable by proprietary software, that's why it's LGPL, that's why ABI
stability is seen as important, etc.

So I'll reiterate that I don't see the point of the bindings release as
you can't make any assumptions at all about what the user has if they
claim to have GNOME bindings 2.8 - it could quite literally be any set
of ABIs at all. Likewise users can't say "Hmm, I have bindings 2.8 but
this app needs 2.6, so it should work". 

If you are going to rely on apt to sort it all out, then quite apart
from shafting ISVs there's also no need for a bindings release as apt
will quite happily (assuming a perfect world) install any old package
regardless of when or how it's released.

thanks -mike