Versioning interfaces

[Tako Schotanus]

Havoc Pennington wrote:

>On Mon, 2005-11-14 at 12:54 +0000, Daniel P. Berrange wrote:
>  
>
>> b) Just tack a number onto the end of the interface name, getting
>>    something like  'org.example.Music.Player2', 'org.example.Music.Player3',
>>    etc, etc.
>>    
>>
>
>This is what most existing frameworks such as COM do fwiw. Another
>convention is to put "X" in there, like "XPlayer" or "javax."
>  
>
Actually Microsoft wasn really sure how to do it and have changed their 
mind several times duringg the lifetime of COM.

So you will see things like:

MSXML.DOMDocument2
MSXML2.DOMDocument
MSXML.DOMDocument.4.0

and several other versions. Microsoft tends to add new interfaces either 
with a number (like DOMDocment2) or with the Ex extension (DOMDocumentEx 
for example) when they _add_ new functionality. The COM system had no 
way of extending interfaces with new backward compatible methods!

In Java you just add/change methods as long as they adhere to certain 
rules. As long as the interface stays compatible Sun does not change any 
names. And as far as I know Sun has never made a change to an interface 
that was not backward compatible (to the implementation, well that an 
entirely different matter, but no versioning scheme will save you from 
that).

The fact that Sun has packages with "x" in them only means they are not 
part of the basic set of java classes but more like an "extra", it has 
nothing to do with versioning.

>Java typically creates a new package with a new API for major changes,
>e.g. io -> nio
>  
>
Well, yes, but we're talking about an entirely different beast here, 
this is not just new io-package that they couldn't make backward 
compatible. The nio package is no replacement for the io package but 
made especially to solve an entire different category of problems (read: 
you don't want to do your normal io with the nio package!).

>  
>
>> In
>>reality many apps will choose c), even though it is truely evil. 
>>    
>>
>
>Well, just because the Linux world seems to be kind of retarded about
>this. Lots of pushback on ometer.com/parallel.html too, for "aesthetic"
>reasons. I think the Java and Windows worlds both "get it" on this
>front.
>
>People are pretty sucky at bumping library sonames too... openssl,
>libpng, etc. all historically screwed up. And libdbus for that
>matter ;-) though we are pre-1.0.
>
>  
>
I think the problem for the linux community in comparison to companies 
like Sun or MS is that we have to live through the entire development 
process, a process that might not always have been entirely thought out 
from the beginning but that has grown over time. Not only the code but 
also the understanding of its developers. Sun and MS will probably go 
through something similar but internally and won't publish interface 
FooBar until it has been tried and tested and found to work (not talking 
about code but conceptually). So in the end, even though the interface 
FooBar maybe has gone through dozens of revisions, several of which 
might have changed it completely, they just call it "FooBar" and all 
incompatible code is thrown away or rewritten before publication.

For the linux/OSS community this just doesn't work because preliminary 
version will already be "out there" and can maybe already be found in 
production systems.

So some kind of system where you say "hey, I need version 3 of this 
interface" is just necessary. So the only thing is, do we use 
get_interface("FooBar2"), get_interface("FooBar.2") or something like 
get_interface("FooBar", 2)?

Although personally I like things "neat" and therefore don't much care 
for FooBar2 there is also the reality that lots of OO languages that we 
will want to map DBus to don't support versioning anyway so any version 
change will have to be reduced to a simple name change anyway (what I 
mean here is that interface FooBar v2.4 will probably have to be mapped 
to eg. FooBar_2 for automatically generated mappings).

Another positive effect of having explicit versioning instead of putting 
it in the name is that you might be able to tell the user what exactly 
is wrong, so instead of "unknown interface FooBar2" you get 
"incompatible version 1.3 for requested FooBar version 2" (hmmm probably 
need a better sentence than that because I'm not sure it is better than 
the first sentence this way hehe).

Another thing to think about is that putting the mayor version number in 
the name still makes it necessary to either have a minor version number 
for backward-compatible changes or to change the name of the interface 
even for those backward-compatible changes.

So in the end, unless we can force developers somehow to really think 
long and hard about the interfaces they design and if we agree that if 
you need a minor version anyway you can just as well implement a major 
version as well I think that going with a version system might be the best

But then again, who am I? :-)
(and if it's all worth the trouble? no idea)

Cheers,
 -Tako