Proposal: how to make incompatible changes

Andrew Jeffery andrew at aj.id.au
Thu Apr 16 14:59:45 AEST 2020


> Applicability.
> 
> These guidelines are for the BMC's "intended external user interfaces".  
> For example, its management interfaces including its web server and all 
> REST APIs.  I haven't given much thought to the BMC/host interfaces or 
> interfaces internal to the BMC.  IMHO, it is less important to maintain 
> compatibility in these areas. 

Lets split this. My feelings are

1. Inband (BMC/Host) interfaces are in the same class as "intended
external user interfaces" and therefore should not have incompatible
changes unless _absolutely_ necessary. What we implement here should
have passed through a specification process under e.g. DMTF.

2. Interfaces between applications on the BMC (e.g. D-Bus interfaces)
is the class where compatibility is less critical, on systems that do not
expose the D-Bus interfaces via REST. However, while any system exists
that exposes the D-Bus interfaces via REST we must constrain changes
to these interfaces as well.

> For example, if you need an incompatible 
> change in an internal interface, you have a smaller set of users who 
> ought to be active in the project, and can give you feedback and adapt 
> within a release cycle.
> 

This is true for interfaces between BMC components, it's not true of the
host firmware interfaces, hence my split above.

When we remove the ability to directly access the D-Bus interfaces via
REST we will gain a lot more freedom as the D-Bus interfaces then truly
become internal.

Andrew


More information about the openbmc mailing list