Re: ABI Compatibility (was Re: Installation woes for the average user...)

[Yavor Doganov]

Richard Frith-Macdonald wrote:
> On 20 May 2009, at 23:17, Yavor Doganov wrote:
> > I am counting only the major releases when there was a soname
> > bump; the regular point releases are not interesting for this
> > discussion.
> 
> Then the discussion seems rather pointless ... since what you are  
> calling the 'major' releases are those were we make ABI changes and  
> bump the soname.

Well, no matter how they're called, that's the core of the dispute:
whether actually there's an ABI break that warrants the soname bump.
If there is a real ABI break -- that's OK, but it if it's just the
feeling "We've accumulated a pile of big changes, so we might be
breaking the ABI; let's force recompilation for extra safety" --
that's a problem.

> the chances are that any individual ABI change will not break your
> application because the app will not be using the feature concerned.

Most probably that's the reason why some people (myself included)
think that some of the soname bumps are unwarranted.  I quickly looked
at the diff between two adjacent releases when the latter claimed to
be "binary incompatible", and surprise -- it really is.  There is at
least one ABI-breaking change which implies a SONAME bump.

I don't have the time to check every pair of recent (>=1.13 for Base)
releases so far, but I'll do it from now on, and I am much more
confident that you're doing the right thing.

> Chasing MacOS-X is a problem for us

I realize this, and I understand that it's hard enough even if one
does not count the various library maintenance issues.  I am not
blaming, and will never blame, for breaking the API or ABI,
being intentional or not.  You are all doing an exceptionally
wonderful job, no matter what.

> Yes, with the manpower they have (and perhaps more importantly, the
> fact that they control the entire operating system) it's relatively
> easy to add runtime tricks to pick the behaviors they want.

I wholeheartedly agree here.  Also, if I may add, judging by the large
piles of code-bases that were made free software through the years,
such approaches are (although smart in some situations) an unportable
mess which has to be rewritten/redesigned some day.

Only the GNU architectures are about 20, with 3 different kernels (and
GNU/kOpenSolaris coming along soon).  Add here the free *BSD family
systems, the proprietary Unices, Windoze, etc...  GNUstep supports
most (if not all of them, to some extent at least), and that's an
enormous effort and achievement already.