Versioning interfaces

[Robert McQueen]

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. :)

> for adding more methods to
> an interface, maybe the versioning is a better approach but here's an
> idea I just had: rather than an explicit version, the "version" is just
> a count of the number of methods and signals the interface has. So if
> you add stuff, the version automatically goes up. It can't go down,
> since to break an interface you have to rename it. If you want to be
> sure you have all the methods you expect, you just require that the
> interface member count is at least what it is today.

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.

Regards,
Rob