[Gtk-sharp-list] API Freeze Policy Adjustment

[Todd Berman]

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
> right.
> 
> 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/
> 
> 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 
release.

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.

--Todd