D-BUS API and ABI (was: Re: ANNOUNCE: D-Bus - 0.31 released)
daniel at fooishbar.org
Mon Mar 7 17:09:52 PST 2005
On Mon, Mar 07, 2005 at 08:00:35PM -0500, Joe Shaw wrote:
> On Tue, 2005-03-08 at 10:17 +1100, Daniel Stone wrote:
> > Just out of curiousity, what's the status of 0.31 with regards to the
> > ABI? 0.23.1, at least (a point release!) broke the ABI by removing
> > a function (renaming it), and didn't bump the soversion -- everyone
> > with stuff built against libdbus who used that symbol had to rebuild.
> > And it silently broke, because packaging systems don't take ABI changes
> > without soversion bumps into account.
> I've been maintaining the 0.23 branch. The intent was to maintain API
> stability for this so we could ship it in an upcoming SUSE release
> without needing to patch HAL and having to depend on what was, at the
> time, a very unstable version in HEAD.
> To clarify: what ABI broke specifically? If you're referring to the
> python change, that was actually an internal API incompatibility. If I
> hadn't missed that bug, everything would have continued working, no?
In 0.23.2, dbus_pending_call_get_reply disappeared (I believe it was
replaced with _steal_reply). I can't remember whether this happened in
.1 or .2.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297020 is the reference
> Anyway, the patch was more than 1500 lines, and it was pretty tricky to
> review everything. I missed something, and I apologize for that. But
> what's done is done. The question now is, what should we do about it?
> If there are actual public ABI incompatibilities, rather than just a bug
> in the python bindings, is it better to revert the changes? Should I
> just bump the soversion anyway?
Ah, it's not the Python bindings at fault. :) But in this particular
case, I strongly believe we should re-add dbus_pending_call_get_reply
as a wrapper around _steal_reply, mark the former as deprecated, and
remove it in a big-ABI-shattering release where we bump the soversion.
> > Which is a shame, because that's a *point* release, so I was really
> > hoping to be able to integrate it, especially for all the Mono fixes.
> Well, I think people put a little too much faith in version numbers,
> particularly for something which is pre-1.0 and requires you to #define
> something saying the API is unstable. :) I would have liked to have
> called it 0.24, but that version was (presumably) taken at the time.
Oh, sure. :) Misplaced faith and all that, but the problem is that
D-BUS is actually being used by real-world apps like HAL, Beagle,
whatever, that people want. That means, by implication, that distros
want to be shipping it as well. Which is why I think that large swathes
of the API that people want to disappear should be marked as deprecated
(hell, print a big-arse warning when people use them), but not actually
removed until a big-ABI-shattering release when the soversion gets
> > And while it's nice to say that it's in beta, that doesn't make apps
> > like HAL, Beagle, etc, just magically go away.
> Well, speaking specifically for Beagle, the fact that dbus 0.23 and
> earlier was buggy to the point of being unusable isn't an acceptable
> situation either.
Oh, absolutely. Which is why I care so much, because we're in the
unenviable situation of having to ship something that breaks ABI. ;)
Not had the opportunity to say it, but thankyou for your work here --
it's been great.
> > Also, breaking API in point releases is generally considered poor form.
> Again, I don't think we should limit ourselves in this way at this
> point. That said, I think everyone here understands the ramifications
> of such changes.
Mmm. I would rather see deprecation rather than removal though, very
Daniel, one of the (less active) Debian D-BUS dudes, Ubuntu D-BUS dude
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050308/d89dbbbd/attachment.pgp
More information about the dbus