Re: API freeze for GNOME 2

[Owen Taylor <otaylor redhat com>]

Maciej Stachowiak <mjs noisehavoc org> writes:

> On 14Nov2001 12:47AM (+0100), Murray Cumming wrote:
> > On Tue, 2001-11-13 at 23:51, Maciej Stachowiak wrote:
> > > * Changes to support language bindings are unlikely to meet our
> > > criteria. It sounds like most language bindings will not be able to
> > > ship simultaneously with 2.0, so there will be time to add features
> > > needed for language bindings after 2.0.
> > 
> > Even if those changes do not break the source or binary API, only add to it?
> > 
> 
> Yes, several board members specifically said that even additive-only
> changes must be curtailed at this point, unless truly critical, and
> that bindings are not critical enough.
> 
> I'm hoping we can make all the neede additions soon after 2.0, which
> works better with the timing of most language bindings anyway.
> 
> (I imagine part of the reason is that if you add an API fairly late in
> the game, you may need to change it afterwards.)

While I agree that we need to clamp down all APIs at this point,
I think there is some faulty logic going on here.

While we aren't going to ship language bindings with 2.0, that doesn't
mean that we should ignore there needs ... if language bindings
need an API upgrade beyond 2.0, that means that they can't ship
until we release 2.2.

The exact same reason that we need to freeze for additions now
are why we can't just throw in additions after 2.0 in an
unstructured fashion:

 - API added without a beta period may turn out to be wrong
 - We need to provide a stable, documented set of APIs, not
   something that is continually moving and forcing people
   to upgrade their libraries for every new app.


My opinion on this is that bugs like:

 - I need to access a struct field directly
 - I need a special-case hack to do this with a language binding
 - I need to duplicate code to do this in a language binding

etc, all should be put off to the future. But bugs of the form:

 - I can't derive from this (important) widget because it doesn't
   expose anything but a new() function and has attributes
   that must be set at creation time.

May require attention for special case exceptions, with consideration
to:

 - Whether the widget is really an important widget (any deprecated
   widget cannot be considered important in this context)

 - Whether deriving from the widget actually is important in 
   language bindings. 

It would be unfortunate if major API in GNOME-2.0 could not be used in
language binding - language bindings are one of our major strengths.
But I don't think it matters much if language bindings for GNOME-2.0
have some ugly code in them or a few corner case limitations.

Regards,
                                        Owen