Versioning interfaces

[Havoc Pennington]

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.

Havoc