Experimental Physics and
Industrial Control System

"J. Lewis Muir via Tech-talk" <[email protected]> · Fri, 10 Jan 2020 11:03:06 -0600

On 01/10, Michael Davidsaver via Tech-talk wrote:
> EPICS is what contributors make it.

That's true, but some things are policy, and to me API/ABI compatibility
is a policy decision made by the project owners.  Adding a tool to
check for API/ABI compatibility is a big help and a critical piece to
maintaining API/ABI compatibility, but unless there's a policy change,
it doesn't change anything in practice.

I want to be clear that I'm requesting a policy change, but I fully
understand that it might not be granted, and I accept that.  I also
understand that it would add a new nontrivial burden to developers.

On the topic of contributing effort toward API/ABI compatibility, I
think that some effort can be contributed, and I think Xiaoqiang's
effort to add the API/ABI checking tool is a great example of this, but
I think I've also sensed the idea that maintaining API/ABI compatibility
is something you can treat after the fact by having someone reviewing
changes for API/ABI compatibility.  I don't think that's the right way
to look at it.  You can't treat security that way: just write the code
and then review it for security afterward.  No, you have to deal with
security as a first-class citizen and design and write in a secure
way to start with.  I feel like maintaining API/ABI compatibility is
similar: developers would need to make changes well aware of any API/ABI
compatibility constraints due to policy (whatever that policy may be).
It shouldn't be that a developer makes a change completely unaware of
API/ABI compatibility policy and then someone reviews the change later
for conformance to the API/ABI compatibility policy.  That would be
very inefficient since the developer might have to completely rewrite a
change because it violates the API/ABI compatibility policy.

If there's no policy change, then I understand the existing policy to be
in effect (and again, I would accept a decision that there will be no
change): there is no guarantee of ABI compatibility whatsoever, even for
a bump of the least significant version number, and API compatibility is
a best-effort compatibility, but again with no guarantee whatsoever.

In practice, what this means is:

1. You're better off always compiling everything from source, and you
   must recompile for anything that depends on something that has either
   changed to a new version (even if the change is a bump of the least
   significant version number) or been recompiled due to depending on
   something that has changed or been recompiled.

2. Creating and using binary packages is awkward at best because there
   is no way to upgrade a binary package safely because any new version
   (even a bump of just the least significant version number) can break
   ABI compatibility.

Lewis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System