Versioning interfaces

[John (J5) Palmieri]

On Mon, 2005-11-14 at 12:54 +0000, Daniel P. Berrange wrote: 
> On Mon, Nov 14, 2005 at 12:20:10PM +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. :)
> 
> Much as I hate to further open a can of worms when we're so close to 1.0, this 
> idea of interface renaming when breaking API doesn't seem to particularly nice
> consequences 
> 
> Thinking about the implications of applying the rule in a real app - say there 
> is an interface defining the API contract for a music player with the name of 
> 'org.example.Music.Player'. Now with a new release, the API is broken for whatever 
> reason, so the interface has to be renamed - how should a new name be chosen ?
> 
>  a) Think of some synonym for 'Music Player', perhaps deciding to rename 
>     to something like 'org.example.Audio.Player'. 
> 
>  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.

I'm not endorsing the idea just yet but this is how it would work under
Havocs proposal.  Say we do have a org.freedesktop.MusicPlayer interface
spec I would think if the spec breaks the API (which it shouldn't do if
it is an adopted standard) you would just rename the interface to the
spec's major number -  org.freedesktop.MusicPlayer.v2.
-- 
John (J5) Palmieri <johnp at redhat.com>