Re: A GNOME Bindings release set?

[muppet <scott asofyet org>]

On Thursday, December 4, 2003, at 03:23 AM, Murray Cumming Comneon com 
wrote:

> > We have bindings for several other gnome libraries but will not 
> > commit those for gnome 2.6.0.  With any luck, we'll have libbonobo 
> > bindings in time for 2.8.0.
>
> Excellent. When you know what they will be, could you please give me a 
> list
> of the tarball names for these, so I can put them on the list.

will do.  of course, the versions will not be finalized until early 
march; shall i just email you when there are new stable versions 
available?


> Do you have some mechanism in perl for parallel installation of similar
> APIs, in case you need to change API for 2.8?

unfortunately, the only way to achieve this in Perl is to install to a 
different prefix and set your perl library path to look there.  that's 
why gtk2-perl uses the Gtk2 namespace instead of Gtk, like we wanted to 
do.

we've also discussed this (at great length on irc yesterday for 
example), as it means that we get one shot.  once it's frozen, it's 
frozen for good.  we are taking this very seriously.

the typical way to handle this is to overload functions to retain 
support for their old call signatures, e.g. add new parameters on the 
end, have funky arg parsing based on argument count, and so on.  this 
is not a lot of fun to maintain or use, so part of our work for the 
next three months is finishing our regression test suite and exercising 
every new API before it gets committed to ensure it is bound correctly 
the first time.

beyond that, the only API changes we'll allow are additions and 
bugfixes (the kind where it doesn't matter that we changed it, because 
before the change it didn't work at all).



honestly, what i'd be most worried about in terms of parallel installs 
and such is avoiding the redhat/pygtk syndrome.  i once tried 
installing meld on redhat 8.0; it wouldn't run because it required 
something in pygtk 1.99.15, but the system had only 1.99.14.  turns out 
the upgrade broke all of redhat's gui config tools.  whose fault is 
this?  pygtk's, for breaking compatibility?  or redhat's for not using 
an unbreakable private installation of pygtk to some separate prefix 
for critical system components?

--
muppet <scott at asofyet dot org>