Re: evolution-data-server D-Bus service version change in 3.29.3

[Simon McVittie <smcv collabora com>]

On Fri, 08 Jun 2018 at 09:03:26 +0200, Milan Crha wrote:
> this is a little heads-up that evolution-data-server 3.29.3 release
> will contain a D-Bus service version change, specifically
>    org.gnome.evolution.dataserver.Sources5
> changes to
>    org.gnome.evolution.dataserver.Sources6
>
> This had been done due to adding a new method to the interface for [1].
> I'd not bump soname version for such API addition, but the D-Bus
> service is a different thing.

Just to confirm what was already said: this change does not require
the D-Bus interface version to be increased, and it is unnecessarily
disruptive to do so, so I'm glad you reverted the change. If
this was needed, systemd's various services would look more like
org.freedesktop.login25 by now :-)

With D-Bus maintainer hat on, if there are D-Bus client libraries that
do not cope gracefully with a method not being present, then I think
those libraries are broken. D-Bus services should raise UnknownMethod
if a client tries to call a method that doesn't exist, and should raise
either UnknownMethod or an appropriate domain-specific error if the method
is known to the D-Bus library but not implemented in application-level
code. IPC clients (including D-Bus) have to cope gracefully with IPC
errors *anyway*, because IPC can fail for various reasons, and it would
be bad for clients to be remotely crashable by their services.

https://dbus.freedesktop.org/doc/dbus-api-design.html
has some useful advice on designing and versioning D-Bus APIs, although
I notice that it currently says

    (This also prevents use of generated bindings; any method which a
    client wants to gracefully fall back from should be called using
    a generic D-Bus method invocation rather than a specific generated
    binding.)

and I'm not sure why. I've opened
https://bugs.freedesktop.org/show_bug.cgi?id=106862 to try to clarify this.

> I'm mentioning it here, because this influences at least Flatpak builds
> of projects using evolution-data-server, like gnome-calendar,
> gnome-todo and gnome-contacts, which build against the latest eds, but
> run backends from the host machine (thus they do not receive all the
> fixes). The Flatpak builds should be adapted accordingly.

Sorry, you can't do that. If a Flatpak app like gnome-contacts wants to
use a service like evolution-data-server from the host system, then
evolution-data-server and gnome-contacts need to stay backwards-compatible
with each other: either one might be newer, depending where you got your
gnome-contacts and evolution-data-server.

    smcv