D-BUS API and ABI (was: Re: ANNOUNCE: D-Bus - 0.31 released)

[Daniel Stone]

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

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

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

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
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050308/d89dbbbd/attachment.pgp