Re: Suggestions for API/ABI Process

[Murray Cumming <murrayc murrayc com>]

On Mon, 2005-08-01 at 10:42 -0500, Brian Cameron wrote:
[snip]
>  > libgtk-1.2.so is clearly different to libgtk-2.0.so and
>  > libgnomprint-2.so is clearly different to libgnomeprint-2.2.so
>  >
>  > No massaging of those numbers, other than having the same names, will
>  > make those libraries ABI compatible. They are different libraries.
> 
> It matters for the following reasons:
> 
> 1) There should be clear rules for how libraries should "rename"
>     themselves when ABI incompatible interfaces are introduced.  The
>     libgtk example is a better naming mechanism because the version
>     change of 1.2 to 2.0 more clearly highlights an ABI difference.
>     libgnomeprint change from 2 to 2.2 seems to indicate a minor
>     release.

Anybody who actually looks at the library names, or at the pkgconfig
names, intending to judge whether they are ABI compatible should know
full well that they are not ABI compatible because they are 2 different
libraries, even if one is called libsomething, and the other is called
libsomething-onlyalittlebitdifferenttrustmewouldilietoyou.

Yes, we can try to create more consistency, and we are already much more
consistent than during 2.0, but in this small case, people won't see it
as having a big advantage.

>     It isn't necessarily bad if different libraries are following
>     different rules.  But if they are, the following needs to be
>     better documented:  what the different rules are, how to tell which
>     libraries are following which rule, and how to tell when an ABI
>     incompatible difference is added to the library by looking at its
>     version number.
> 
> 2) In order for GNOME's API/ABI policy to be meaningful, Stable
>     libraries should not change ABI in the GNOME 2.x timeframe.
>     So, either libgnomeprint* isn't Stable ABI that people should
>     use, or GNOME should have been bumped to 3.0, or this ABI
>     change was a mess-up that we should learn from and avoid in the
>     future?
> 
>     If the answer is libgnomeprint* isn't Stable because it is not a
>     part of the Platform interfaces, then this might not be a great
>     answer.  It's hard to imagine that ISV's won't want access to
>     the library that gives programs access to printing.  Do libraries
>     migrate from Desktop to Platform when the GNOME community
>     recognizes that ISV's might need to use the library?

Yes, we should have a decent printing API, but we shouldn't pretend that
we have one before we have one. The libgnomeprint API is just not good
enough to commit to for the next decade or so. Getting these APIs
finished and into the Platform is more important, I think, than
documenting quite how crap they are while in the Desktop.

Luckily, we are getting there. libgnomeprint* will get a dose of cairo
sanity, evolution-data-server is being cleaned up and will get in
eventually, gstreamer is ever closer.

> In other words, I'm not trying to suggest that anything is wrong
> or broken.  I think the main problem is that the processes are not
> documented, so the situation seems confusing.

Fair enough.

>   And this makes it
> look, in my opinion, like we're not doing a great job when we really
> are.  Perhaps things like how API/ABI rules change between desktop
> and platform interfaces is clear to some people in the GNOME
> community, but how can the general public (including ISV's) know
> the difference if it isn't documented clearly?
> 
>  > Brian, may I edit http://live.gnome.org/InterfaceSpecification for
>  > brevity? You might want to keep a copy of the original in case you don't
>  > like the result.
> 
> Please update it.  It is on live.gnome.org so it can be a living
> document that best reflects the way the GNOME community views interface
> stability on the desktop.

Thanks.

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com