Hi On Tue, Sep 22, 2020 at 8:11 PM Markus Armbruster <arm...@redhat.com> wrote:
> Marc-André Lureau <marcandre.lur...@redhat.com> writes: > > >> * Adding results > > > > Also change the signature of the function. > > > > However, since messages have boundaries, it is easy to ignore return > values. > > I'm not sure I understand this. > > The compatible change I have in mind is adding members to the complex > type returned by a command. > There are certain things you can do in D-Bus, just like we do with JSON. You could ignore the signature checking, you could ignore some extra message fields... That's not what people usually expect. D-Bus is a machine and bindings friendly. It's not meant to be so lazy. > >> We've made use of this extensively. See also > >> docs/devel/qapi-code-gen.txt section "Compatibility considerations." > >> > >> How do such changes affect clients of the proposed D-Bus interface? > > > > The introspection XML will always reflect the expected signature. You > > should bump your interface version whenever you make incompatible > > changes. > > How do "interface versions" work? Client's and server's version need to > match, or else no go? > > The D-Bus specification doesn't detail versioning much. What is recommended is to have the version number as part of the interface name (kinda like soname): http://0pointer.de/blog/projects/versioning-dbus.html (this is documented in several places iirc) So a QEMU D-Bus interface could have a name like org.qemu.Qemu51, org.qemu.Qemu52.. for example, if we can't provide better API stability... -- Marc-André Lureau
