Re: moving to dbus 0.3x asthe target version for G2.12 [was Re: DBus in G2.12]

["John (J5) Palmieri" <johnp redhat com>]

On Fri, 2005-06-10 at 19:43 +0200, Jan de Groot wrote:
> On Fri, 2005-06-10 at 10:23 -0400, Luis Villa wrote:
> > [Moving this off r-t to a broader group that might have more feedback on this :)
> > 
> > On 6/10/05, Vincent Untz <vuntz gnome org> wrote:
> > > On Fri, June 10, 2005 15:22, Ross Burton said:
> > > > I think the release team need to make a statement about what version of
> > > > DBus is to be used for any code which can use DBus.  At present I
> > > > believe gnome-vfs and HAL in CVS are using the DBus 0.3x API, whereas
> > > > nautilus-cd-burn is still using 0.2x.  As these cannot be easily used at
> > > > the same time, this needs to be resolved one way or another.
> > > 
> > > Good point. I think that the distributors that will ship 2.12 will use
> > > DBus 0.3x. Going with the DBus 0.3x API looks like the more sensible
> > > solution to me. Is there any reason to stay with the 0.2x API?
> > 
> > Yeah, I don't know of any reason not to standardize on 0.3x- most
> > things have already ported AFAICS. d-d-l, anyone object to requiring
> > everyone to move to 0.3x? (I'm assuming no, but...)
> > 
> > Luis
> 
> As distribution packager, I already followed the DBUS 0.3x road once,
> and it went dead because it seems only gnome and freedesktop are picking
> up the new APIs. How will interoperability with other programs, like for
> example, KDE look in the near future with DBUS 0.3x?
> As it looks now, I can't provide prerelease packages to our users
> without breaking KDE for them, which is bad (I build gnome-vfs without
> DBUS in my prerelease packages, but I don't think that option will last
> very long)

Turn off support in KDE or patch the applications.  I don't think it
uses DBus for much.  Qt4 will be using DBus extensively from what I
hear.  The thing is 0.2x was added to distributions so that people could
play with it and those who were willing to wade the waters of a changing
API could do useful stuff with it.  It really is a dead branch though
and I really don't want to promote its use any longer.  It will just get
harder to switch once we do reach 1.0 and commit API/ABI stability.
Uptake on the library was faster than what we had expected (a testiment
to its utility) but we are going to have to feel the pain at some point
and now is the best time.  Point being, staying on 0.2x just digs a
bigger hole of which one would need to climb out of.  The release I want
to do next week should be for the most part API stable up to 1.0 (baring
any limitations the Qt4 people find).  At least we won't be seeing the
massive changes that took place between 0.2x to 0.3x so lets get it over
with and not prolong the inevitable.    

-- 
John (J5) Palmieri
Associate Software Engineer
Desktop Group
Red Hat, Inc.
Blog: http://martianrock.com