[Gtk-sharp-list] API Freeze Policy Adjustment
Thu, 01 Jul 2004 18:14:42 -0400
I didn't want to reply again, but I feel I have to, I will attempt to
make it short though. (inline)
Murray Cumming wrote:
> On Thu, 2004-07-01 at 17:41 -0400, Miguel de Icaza wrote:
>>And I have never heard of a good argument against adding APIs. You
>>keep trying, but other than `thats what we do around here' you have not
>>articulated why this is good.
> I will try to expand my previous reasons for you:
> 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.
> 1.2 It allows new API to be tested properly in unstable releases,
> instead of suddenly appearing in a minor stable release.
> 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.
Again, you talk about large new API, and I don't think anyone has
suggested adding 'large new API', just cleaning and polishing existing API.
>>You keep trying, but you keep not articulating your reasons.
> Let me make it clear again. These are not my policies. These's are
> GNOME's policies. The release team just tries to represent the consensus
> and provide a framework in which they want to work. However, I
> personally happen to think that the GNOME community has got things
> 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:
> 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.
They aren't, and 1.0 is already out, so whats the deal?
> But I would like to see mono bindings, and other bindings, being taken
> as seriously as the GNOME Platform's C APIs. Only then will people be
> comfortable with developing core GNOME Desktop applications with these
> languages. Choice is good. Chaos is bad.
How exactly will mono bindings being inside this platform release set
change the fact that nothing but C is allowed in the core GNOME Desktop
Inclusion in some random binding release set is unimportant when GNOME
itself doesnt allow anything but C in the core GNOME Desktop release.
In fact, the only language that seems to be considered for allowable
inclusion in the core GNOME Desktop release is python, which isnt a part
of your binding set.
And I think the outpouring of mono/gtk# apps that you can see shows that
people already take it seriously. Being included or not in any binding
release set wont change that.