[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 13.04.07 13:02:35, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > 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:
> > [snip other options]
> > e) implement IFoo+IFooV2+IBar, thus make sure it is found when any code
> > needs any of the 3 interfaces. 
> 
> That's exactly what I'm afraid of, but unless we can create IBar and 
> IFooV2 and arrange for IFoo to become IFoo : IBar, IFooV2 (without 
> breaking BC) then we're stuck with this. I guess we'll just hope this 
> never comes up. :-)

Why should we need this? e) is the way to go and there's no problem if a
plugin "suddenly" adds an interface I think (wrt BC). We don't care
about BC of plugins, because nothing links against a plugin. Thats the
whole point of us using the extension interface mechanism from TT and
not just plain C++ Interfaces. Alexander has a small demo that proves
you can break BC in a plugin without affecting code that uses the
plugin.

Andreas

-- 
You look tired.