[Gtk-sharp-list] API Freeze Policy Adjustment

[Murray Cumming]

On Thu, 2004-07-01 at 22:46 -0400, Jonathan Pryor wrote:
> On Thu, 2004-07-01 at 20:02, Murray Cumming wrote:
> 
> You touch on one important detail, which also highlights a difference
> between Gtk# and GNOME:
> 
> > You need to make unstable releases to test large new API. APIs are not
> > born perfect, and people don't test them enough when they are just
> > sitting in CVS. In fact, the need to have them tested in CVS can make
> > you too scared to release a tarball to provide other unrelated
> > improvements. This unstable/stable release schedule is a major reason
> > for GNOME's quality success since GNOME 2.0, compared to the chaos and
> > awful APIs of before that. That's not a controversial opinion.
> 
> The important difference is this: most of Gtk# is a very low level, thin
> wrapper of the actual GNOME libraries.  The Gnome libraries benefit from
> the stable/unstable release cycle because they're releasing libraries
> which haven't been used before, so getting feedback is important before
> ensuring API/ABI stability.
> 
> Much of Gtk# is different: new API, completely untested, isn't being
> written.  Wrappers for existing code are being written, as well as
> helper overloads for existing code.  This is a significantly simpler
> operation, with fewer concerns about "screwing the API up".

Yes, it's easier to get the API right, but your API will still not be
perfect from the start. You have changed API after you first wrote it
and you will again.

We need to be very careful when changing any API when we don't have the
chance to change it again.

I do have a great deal of experience with this situation.

> For more "enthusiastic" API additions -- code which isn't just a thin
> wrapper over existing libraries, but is instead a substantial change in
> their own right, such as Data Binding and similar functionality,
> *should* fall under the traditional stable/unstable release.  This makes
> more sense, as it can benefit from the increased testing and feedback
> cycle, contributing to a higher quality API.

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