Versioning interfaces

[Robert McQueen]

Daniel P. Berrange wrote:
> Option b) just
> plain sucks, because it is defacto encoding versioning info in the interface 
> names - where its completely opaque to any versioning resolution logic.

Yes, it is completely opaque to any versioning resolution logic. The
point is that this is equivalent to raising the major version number of
your interface, effectively saying that some previously existing methods
and signals that used to exist don't exist any longer. If you break your
interfaces, things that used to work don't, so you can't assume anything
works any more. This is how shared library versioning works already
unless you start versioning each and every symbol.

> In
> reality many apps will choose c), even though it is truely evil. 

I think this is the current de facto state, because there is no capacity
for versioning in D-Bus interfaces as it stands, and even us (the D-Bus
upstream) are in the process of making incompatible changes to our
interfaces without making it evident in the versioning... :)

> I don't think any of these three outcomes are particularly desirable, thus
> unless there is an awesome option d) i've not thought of, I can't help be
> think we need to do a more explicit versioning scheme. Major/minor pair,
> arbitrary levels of '.' separated digits x.y.z/x.y.z.a, or perhaps just
> follow the libtool 'CURRENT:AGE:REVISION' versioning scheme [1]. 

My proposal was at the start of this thread, and was just to do a pretty
standard major.minor.patch annotation on interfaces, with the usual
logic: if I was coded against version major.minor.patch, I will work if
my major version matches the service, and the minor version is greater
than or equal to theirs.

> Regards,
> Dan.

Regards,
Rob