[Gtk-sharp-list] API Freeze Policy Adjustment

[Murray Cumming]

On Thu, 2004-07-01 at 18:14 -0400, Todd Berman wrote:
> 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.

Use of C in the GNOME DEsktop is a) Not actually official anywhere, so
there is no offical obstacle to the use of another language in the GNOME
Desktop. Although it's not a big departure, Epiphany and GnomeMeeting
use C++, though they don't use the C++ bindings.

It is not love of C that is keeping GNOME Desktop applications in C. 

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

Yes it is.

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

I don't think you even know what you are arguing about anymore.

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