Announcing dbus 1.6.0

[Simon McVittie]

On 05/06/12 15:55, Colin Walters wrote:
>> Forking dbus into a thread-safe library for apps (QtDBus etc.) and an
>> OOM-safe library for critical system services (dbus-daemon, systemd,
>> Upstart etc.) also seems like a bad move when we're still clearing out
>> "technical debt" from libdbus
> 
> That makes sense; again though, my question wasn't "why isn't this in
> 1.6??!", it's more that I'd added a mental note around the threading
> issue as "may affect SSSD/libvirt".

If we did fork libdbus like this, I would consider "libdbus is no longer
thread-safe" to be an incompatible change, and bump the SONAME (or
change the library's base name) accordingly. (After all, it's a change
that would break previously-correct applications - notably, QtDBus uses
libdbus and claims to be thread-safe, and multi-threading seems to be
generally more popular in the Qt world.)

I'm not so sure what I think about whether "libdbus no longer pretends
to cope with OOM" is a compatible change; that could be argued either way.

The other two things you noted are the closest we got to incompatible
changes in 1.6. I considered them to be "basically compatible" (enough
to not bump the SONAME), because eavesdropping is meant to be a
developer feature rather than something that real applications use, and
I can't see any reasonable justifications for non-default threading
primitives except "my platform doesn't have pthreads at all" or "I'm a
developer and I want debug messages about locking", either of which
would be better solved by patching libdbus, IMO.

The other things I'd suggest watching out for are that epoll support
required some refactoring, and it's possible that bugs crept in during
that process; and systemd-based at_console detection is probably not as
well-tested as the ConsoleKit version.

    S