[Gtk-sharp-list] API Freeze Policy Adjustment

Miguel de Icaza miguel@ximian.com
Sat, 03 Jul 2004 17:05:59 -0400


   First of all, thanks for your description.

> I think the reasons are:
> 1.1 It avoids confusion by having too many versions of the API.
> Developers don't have to ask think too hard about what version of the
> API they are targetting, because there are usually just 2 widely-
> deployed, clearly-defined APIs. This is mostly a matter of making life
> simpler for developers and distributors, but I think that's a very good
> reason, particularly when the time to wait for a new stable release with
> your new API is rarely more than 4 months. 

This would work if there were no micro-releases of software, but in
reality bug fixes are done, and developers *have* to worry about a
minimal package version for their software, it is not really something
they can just forget.

So it looks nice as a policy, but it is disconnected from reality. The
day Gnome and Gtk does not ship any maintenance releases, is the day I
will buy into that argument. 

> 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.

That is a side effect: there is no reason why an API can not be tested
before a release, so this is not really an important point.

> If you disagree with the current API/ABI guidelines and/or the GNOME
> time-based release process then please talk to the GNOME community about
> it. Before doing that, I encourage you to read our notes about the GNOME
> release process:
> http://developer.gnome.org/dotplan/

I disagree, but I have more important things to do than change Gnome's
release process.  Specially since the Gnome release process *has
nothing to do* with Gtk# and Mono.

And Mono and Gtk# are not Gnome and not part of Gnome.

Just like `X11', `Cairo', `glibc', `python' and others.  We have
different motivations and different reasons for doing this.

We are doing this to help Gnome, but we are not subject to the project

> And I'll make it clear once again: You can do whatever you like with
> Gtk# 1.0 as long as it's not in an official GNOME release set.

Thank god that we have some freedom.