[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 12.04.07 16:43:29, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > On 12.04.07 14:31:49, Matthew Woehlke wrote:
> >> Andras Mantia wrote:
> >>> On Thursday 05 April 2007, Andreas Pakulat wrote:
> >> I just realized a potential issue; do we have a plan for how to go about 
> >> splitting an interface without breaking the API/ABI if that should be 
> >> needed? E.g. if we have an interface that provides foo and bar, and 
> >> later want to implement a back-end for a VCS that only provides bar, 
> >> what happens?
> > 
> > Well, without much thinking I'd say: create 2 new interfaces. This of
> > course won't work for the main interface, but all optional should work.
> 
> Well, yes. The question is can you do something like go back and change 
> the interface that provides both to being a class which implements both 
> the new interfaces? Otherwise now you have two problems. First, you have 
> three interfaces where A+B provides the same features as C. Second, you 
> have to update everything that provides C to provide A+B.

Uhm, we don't have to do anything (well we'd probably update svn+cvs),
the plugin developers would do this. I talked a bit with adymo about
interface versioning on IRC (yes I know bad place, no history). The
outcome is basically that in this case it would work like this:

IFoo is the original interface from which we split out foo (bar stays in
it). Thus we create IBar with foo() and we also create IFooV2 which only
has bar(). Now a plugin has a couple of choices:

a) Implement IFoo and only be available for other plugins/scripts that
still use IFoo
b) Implement IFooV2 and thus make sure it will only be found when
somebody needs the bar() method
c) implement IBar because it only wants to implement foo()
d) implement IFooV2+IBar and thus make sure any code that is created
after the separation gets this plugin when asking for either of the
interfaces
e) implement IFoo+IFooV2+IBar, thus make sure it is found when any code
needs any of the 3 interfaces. 

> I'm not sure if there is any way around that, though, other than perhaps 
> do this preemptively (i.e. except for the basic interface, not make any 
> interface that provides more than one sort of function).

I was going to try to find reasonable grouping anyway.

Andreas

-- 
You too can wear a nose mitten.