Re: EPICS release series after 7.0: 7.1 or 8.0?

[Michael Davidsaver via Tech-talk <tech-talk@aps.anl.gov>]

On 1/10/20 12:37 AM, Wang Xiaoqiang via Tech-talk wrote:
> Hi Andrew,
> 
> Here is a test run between 3.14.12.7 and 3.14.12.8, (compiled with HOST_OPT=NO).
>   https://xiaoqiangwang.github.io/epics-base-api-checker
> 
> It does not show any ABI breaking. Or is there something it does not detect, as Michael expects?

You didn't miss anything (or we both did).  As far as I can tell, there were
actually no ABI changes at all in 3.14.12.8.  (which I didn't know ahead of time)
I was curious to find if anyone was motivated enough to actually check.
EPICS is what contributors make it.


> Best
> Xiaoqiang
> 
> On 1/9/20 10:51 PM, Johnson, Andrew N. wrote:
>> Hi Xiaoqiang,
>>
>> On 1/9/20 2:47 AM, Wang Xiaoqiang wrote:
>>> It is understandable ABI/API compatibility has never been a concern of the core developers and an extra burden with no immediate benefits. But this becomes essential for sites (increasingly) using central deployment.
>> Please note, API (i.e. source-code) compatibility between releases has been a major concern of core developers for many years, I already described how we treat that in another email in this thread. Our position on ABI compatibility though has been that we don't have enough developers to promise that, so users should recompile from source whenever they upgrade Base. By concentrating on API compatibility we can reduce the burden on users when they do upgrade despite our only having a small group of core developers. If ABI compatibility were really essential to a site they would be throwing effort or money at us to actually implement it (nobody has yet).
>>
>>> I assume this ABI checking can be one additional step in the CI script, using tools like abi-compliance-checker. It could then be used as a guideline in development. e.g. attached is a generated report of pvAccess library between 7.0.2 and 7.0.3.
>> That output does look good, I'd love to see the tool being run automatically against all our shared libraries whenever we commit changes to our Git repo's. It would be interesting to see what results it gives for Michael's challenge.
>>
>> - Andrew
>>
>> -- 
>> Complexity comes for free, Simplicity you have to work for.
>>