Versioning interfaces

[Tako Schotanus]

Havoc Pennington wrote:

>On Mon, 2005-11-14 at 12:20 +0000, Robert McQueen wrote:
>  
>
>>Havoc Pennington wrote:
>>    
>>
>>>Historically my thought on that has been to just use the COM rule (if
>>>you change an interface you rename it). I think the COM rule is probably
>>>right for *breaking* an interface at least...
>>>      
>>>
>>This is reasonable, I'm not too keen to waste time arguing it. :)
>>    
>>
>
>It's not worth wasting time on arguing for its own sake, but it's
>certainly worth discussing enough to understand all the issues.
>So I appreciate everyone's posts on this.
>
>  
>
>>It took me a long time to realise why this wouldn't work (nobody else
>>does versioning this way), but when redrafting the interface
>>specification for our project yesterday, I realised the problem.
>>Counting interfaces/signatures does not take account of when you add
>>functionality to an existing method in another direction, such as making
>>a previously invalid input (a new enum constant) valid. Between version
>>1.1 and 1.2 of an interface, the methods might not change necessarily,
>>but a new constant FOO_BAR_STATE is added which can now be understood by
>>the methods or emitted in signals. Or something like that.
>>    
>>
>
>If the old methods accept this new constant, in the COM world the answer
>would be "you have to rename," yeah.
>
>But here's an offhand thought that may suck:
>
> - we autogenerate a base version as the count of members in the 
>   interface
>
> - we have an optional annotation "extra version" which is a number
>   to be added to that base count
>
>So the idea is that if you make a change that somehow adds to but
>doesn't break an interface, and does not add any new methods or signals
>in the same release, you could bump the optional annotation. If you
>happen to add a method/signal at the same time as the new enum value (or
>whatever) then you still don't have to use the annotation.
>
>Maybe too complicated, but it avoids the issue of people forgetting to
>increment "soname" (or just not feeling like it) since if they add
>methods they can't avoid it.
>
>  
>
I still like the simplicity of the basic idea and I understand that 
having an automated way to get a version number would be great, but I do 
see some possible problems with your suggested "extra" number which gets 
added to the base count.

Just imagine an old interface with an extra count of "1" and a newer 
interface with one new method (without arguments) where they left out 
the "extra" count. They would suddenly be the same.

Wouldn't having both systems work?
Use the automated method/argument count always, because it will at least 
detect interfaces that really are not compatible and an optional 
major.minor version number in the annotations.

That will give you the ability to ask for a specific version of the 
interface while safeguarding against lazy or forgetfull programmers. And 
at the same time it makes versioning easier because asking for version 
2.1 is easier than having to look up somewhere what the "count" is for 
that new interface that you need.

BTW, what was the reason again for flagging interfaces that have new 
methods as incompatible with older versions? Is that because we can't 
make that work in all language bindings? I know there was a good reason 
but I can't seem to remember :-)

Cheers,
 -Tako