Proposal: how to make incompatible changes

[Andrew Jeffery]

On Mon, 27 Apr 2020, at 23:17, Brad Bishop wrote:
> at 10:56 AM, Patrick Williams <patrick at stwcx.xyz> wrote:
> 
> > On Thu, Apr 23, 2020 at 12:20:53PM -0400, Brad Bishop wrote:
> >> at 8:11 AM, Alexander Amelkin <a.amelkin at yadro.com> wrote:
> >>
> >>> Internally, for inter-process dbus communication the interface version
> >>> could be checked during compile time to prevent problems that couldn't be
> >>> detected by compiler/linker automatically.
> >>
> >> I like the idea of a stable, versioned DBus API.  Does anyone else?
> >>
> >> In the past there was opposition to that.  I’m not sure if there still is.
> >
> > Since we're deprecating the REST-dbus path and moving towards Redfish is
> > there much advantage to a versioned DBus API?
> 
> It helps lower the barrier to comprehension and entry.  Unversioned &  
> unstable IPC APIs are not normal and probably shocking to anyone that comes  
> across them.
> 
> An unstable, unversioned API encourages bad behavior - e.g. I can just make  
> this in-compatible change to the API and fix all the applications at the  
> same time.  lock-step dependencies between 3 different projects  
> (phosphor-dbus-interfaces, the client, and the server) is not a good thing.
> 
> Put another way - with an unstable and unversioned API - what is the point  
> of having all these different projects and repositories?  It just becomes  
> one giant monolithic code base.  If that is what we want, then we should  
> structure it that way.  Nothing inherently wrong with that, but it seems  
> like it would restrict how the code can be used.  Does that bother us?
> 
> > Alexander mentioned
> > compile-time checking of the interface, but we already have that through
> > sdbusplus.  The issues are:
> >     1. Client bindings are not currently being generated.
> >     2. Not every implementation is using them.
> >     3. We don't have a good mechanism to deal with cross-repository
> >        interface changes.
> >
> > I don't think a versioned DBus API solves any of these, except maybe #3
> 
> That's just it - these are the solution to the problems that an unstable  
> and unversioned API bring, not the other way around.  It is all work one  
> way or the other - we can do something atypical like have an unversioned  
> and unstable API, and then write a bunch of frameworks and tooling around  
> that so that it can work.  Or we can put in the effort to have a stable and  
> versioned DBus API.  I would rather do the latter because that is how  
> people have been using dbus effectively for a really long time.
> 
> > but that is only if we're going to write servers that support N-versions
> > of the interfaces.
> >
> > It seems to me like a better investment is #1 and #2?
> 
> To be clear on #2, use of frameworks is an optional thing.  To get  
> universal adoption of a framework, you have to first get universal  
> acceptance of the merits of the framework.  So I suggest interlocking with  
> the specific application maintainers before working on #2 to avoid wasting  
> time.
> 
> > I'd personally
> > like to have #1 implemented by the end of Sept at the latest.
> 
> Nice!
> 
> > Solving
> > #3, I think, requires us to do some CI investment to support Gerrit
> > topic-based testing.
> 
> Or we can avoid entirely, with a stable, versioned API :-)
>

+1 for stable, versioned APIs.