Re: Gtk# in 2.16

["Elijah Newren" <newren gmail com>]

On 4/24/06, Mike Kestner <mkestner novell com> wrote:
> > To clarify, this means you're targetting Gtk+-2.10 for Gnome 2.16, right?
>
> Yes.

Great!

> > Why are you unable to comply with that one -- what would be difficult
> > about putting the API/ABI stable bindings into one package and putting
> > the other bindings in a separate one?  Wouldn't it just mean that
> > people who want to use the extra bindings install both packages?  I
> > feel like I'm missing something because I would have assumed this was
> > the easiest requirement to comply with (though I'm obviously no expert
> > in the area...)
>
> In my opinion, it would just make more work for me to release Gtk# and
> more work for our users to download and build it, and more work for our
> packagers to package it, etc...

Well, to let you know where I'm coming from, I'm the one that
constantly nagged until python was split up more (so that now there is
gnome-python, gnome-python-desktop, and gnome-python-extras).  I even
suggested kicking gnome-python from the bindings if various issues
weren't resolved (though, they were, which is good -- and much
preferred).  So, I hope I don't come across as a jerk (though I
probably will and I apologize for that in advance), but I strongly
agree with the rationale for the split...

A quick search seems to turn up
 http://mail.gnome.org/archives/release-team/2005-November/msg00058.html
 http://mail.gnome.org/archives/desktop-devel-list/2006-January/msg00116.html
with my previous comments on the matter though I'm sure there's
probably others I'm missing.

> My recollection of the initial process that defined the rules was that
> everyone who commented on that particular rule except for Murray thought
> this was not important.
>
> http://mail.gnome.org/archives/language-bindings/2003-November/msg00013.html
>
> Murray's primary argument seemed to be about the marketing aspects of
> guaranteeing API stability which a non-platform lib couldn't do.  The
> reality is that we've been able to maintain our API stability guarantee
> despite the presence of Desktop libs in our set.

Reading through, it appears that muppet also thought it was
worthwhile, and java and python have long since adopted it, AFAICT.

You may have been able to maintain API stability so far for such
modules, but I don't see how it's reasonable to claim that you'll be
able to going forward (unless you also maintain the relevant desktop
modules, have promises from their maintainers, or happen to know that
they're dead an unrevivable and thus API stable  ;-)

Maybe it's just me, but I really don't see how it makes sense to
include API-unstable stuff in a module that's part of a release set
that guarantees API stability.

> I don't personally see the value of the split between Platform/Desktop
> in a language binding.  Maybe if that rule is written in stone, Gtk#
> could be added to the Desktop release instead of the Bindings set.  ;-)

Hehe.  ;-)  I'd dislike that route though; I think the API/ABI
guarantess of the bindings set are valuable and should be reached for
where possible.  Also, doing something like this would seem to
diminish the value of the bindings release set, which I would not like
to see.


Just my random $0.02,
Elijah