RE: A GNOME Bindings release set?

[Murray Cumming Comneon com]

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

I just want the names, not the numbers. For instance, the something in
something-0.1.0.tar.gz.

In future, we might impose some version numbering schemes, but it's too late
for that in this release cycle.

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

Well that's a fairly good mechanism. So, do remember that you will not be
allowed to just break API/ABI for 2.8 without using a different prefix.

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

OK, understood. No breaks until GTK+ 3 for you then.

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

That's a good idea anway. It's a pity that perl doesn't make
parallel-installation easier.

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

Yes, I have done similar nobody-could-have-been-using-it-before-anyway
changes before, but quietly.

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

Firstly, that was an unstable development phase (1.9.x, not 2.0.x).
Secondly, that's why we will not allow any API additions in one release
phase. So, you would make API additions for 2.7/2.8, but not for 2.6.1,
2.6.2, etc. That simplifies things a lot.

Murray Cumming
www.murrayc.com
murrayc usa net