[Gtk-sharp-list] The state of GTK# (Christian Hoff)

Vladimir Giszpenc vladimir.giszpenc at gmail.com
Wed Mar 10 12:35:06 EST 2010


Awaiting a 3.0 that will never come is unacceptable.  I am a
developer.  I don't need the latest features in Gtk#, but I may want
the features I am adding so I can use them in my application.  Trunk
is not a version in my book.  It needs to be a version that is
distributed by Novell.  I might call it 2.200 so it is not 3.0 but
there is a clear numbering jump.  Numbers are cheap.

Release early, release often is good for users and developers.
Releasing regularly does impose a testing cost but with each feature
that is added, hopefully more users and developers are converted to
the cause.

Backward compatibility would break with 2.12 since it would not
support 1.1 but that is a price we are all paying now as opposed to
just that community.  Right now there is NO version of Gtk# beyond
something over a year old.  backward compatibility is not worth never
releasing a version.  I understand there is work in trunk, but if you
can't get guarantee I will be able to use the functionality within six
months, then I can't afford to invest in it.


> As far as 2.0 dependencies go, we have already added the dependency in
> trunk, so we can use features like [UnmanagedFunctionPointer].  Efforts
> to move to generic collections can proceed in trunk.
> There will also hopefully be significant deprecation cleanup in trunk
> before 3.0, so anyone who wants to contribute to that effort is welcome
> to do so.  Most of it will be automatic because the native API is
> removing them, but we can probably remove most of the workaround and
> stability deprecations as well.
> Perhaps you were looking for these changes to be done in 2.12?  We could
> not do that and maintain our stability guarantee or provide continued
> support on mono's 1.1 profile, of course.

More information about the Gtk-sharp-list mailing list