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