Versioning interfaces

[Tako Schotanus]

Robert McQueen wrote:

>Tako Schotanus wrote:
>  
>
>>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.
>>    
>>
>
>This is a red herring, you can engineer exactly the same breakage with
>manual major/minor version annotation. If you lower a number, you break
>it. :)
>
>  
>
I'm an outsider to this discussion and not trying to use tricky language 
constructs to influence the outcome ;-)
I also thought (see below) that this was for major versioning where 
regressions in numbering might be normal (after a new version of the 
interface) but if it's used for minor versioning only any large change 
means a change in name/major number anyway.

>>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.
>>    
>>
>
>Having both seems like complete nonsense: see below. Interface names
>behave like major version numbers, and the minor version number is what
>we are talking about with the automatic counting.
>  
>
Ah, ok, that was the thing that I had forgotten, the number is meant for 
minor versions, that explains the mistake in my thinking (well it least 
it does to me ;-).

>  
>
>>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.
>>    
>>
>
>Lazy and forgetful programmers can always break any system, be it manual
>or automatic. We have to assume someone implementing an interface is
>doing so to provide a service to a client, not an IPC assault course.
>  
>
Then why have an automated system? You suggest that people look up the 
"count" for the specific interface they want?  Let's say I want version 
2 of the FooBar3 interface, how must that be handled? How do I know what 
to ask for?

>  
>
>>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 :-)
>>    
>>
>
>No, if we implemented only a single number, it would be a like the minor
>number. We can interoperate with the service if it's version is greater
>than or equal to the one we're expecting.
>
>The major part would be done by implementing a new interface. If you
>consider it, major version numbers on an interface just behave like part
>of the name anyway, but it's just becomes a way to fool a client that
>you can service it until it does a version check, or a way to break the
>client if it doesn't. I tend to agree with the "suggest a convention for
>renaming the interface
>  
>
Well not exactly, there is information inherent in asking for version 2 
of interface "FooBar" that you cannot reliably deduce from a name like 
"FooBar2". Having seperate versions with the same name explicitly states 
that both implement the same service but that version 2 is newer than 
version 1, with FooBar2 there could be doubts (Does the ConvertToHTML4 
interface mean that it is the 4th version of the ConvertToHTML interface 
or is it the first that converts to HTML4?)
Another very simple example is that when asking for not supported 
version 2 of interface FooBar you could show better messages than just 
"unknown interface FooBar2".

>I'm quite happy with the concept of using a count of signals/methods
>plus a delta to work this out. The only question is where we implement
>it... in the bindings where they parse the introspection data? The delta
>can become an annotation on the interface.
>  
>
Of course I understand that just changing the name and having a 
method/signal count is a lot easier to implement and that might in the 
end be the most compelling reason to use it.

>  
>
>>Cheers,
>>-Tako
>>    
>>
>
>Regards,
>Rob
>  
>
Cheers,
- Tako