RE: EPICS release series after 7.0: 7.1 or 8.0? (ABI)

[Mark Rivers via Tech-talk <tech-talk@aps.anl.gov>]

> If EPICS and all of the EPICS modules cared about API and ABI compatibility, I suspect they would not break it as often, 
> and I think this would result in an easier time upgrading EPICS and EPICS modules in that I wouldn't have to change as much source code for API changes, 

Can you tell me the last time you had to change your source code for an API change?  
Was that a change you think could be been avoided, and how?

> and I would have a better chance of avoiding so-called "dependency hell."

Please describe the last time you had a "dependency hell" with EPICS.

Mark

-----Original Message-----
From: J. Lewis Muir <jlmuir@imca-cat.org> 
Sent: Thursday, January 9, 2020 4:01 PM
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: Michael Davidsaver <mdavidsaver@gmail.com>; tech-talk@aps.anl.gov
Subject: Re: EPICS release series after 7.0: 7.1 or 8.0? (ABI)

On 01/09, Mark Rivers wrote:
> I am trying to understand your motivation in pushing for ABI compatibility.  Can you please explain clearly how you will use this, and how you think it will save you time and effort?
> 
> As far as I know you are responsible for the control system on a single beamline with a single experimental station.  How much time do you estimate you will save by being able to upgrade EPICS with binary modules, rather than just building base and synApps from source?
> 
> I run 4 beamlines with 5 experimental stations, and the build and deploy process does not take much of my time.

Whenever I upgrade, I spend a fair amount of time downloading all the distribution files, patching, and getting everything to build correctly.
I wish to have binary packages that I could build once and then install on Linux and macOS machines.  I was thinking of using pkgsrc so that I could use one package management system to build and install binary packages for a number of platforms including Linux and macOS.  Then, for example, it would be as simple as "pkgin install epics" to install EPICS on a machine.

The motivation for wishing for ABI compatibility is mainly to make the package management possible so that binary packages for EPICS and EPICS modules could be installed and upgraded independently without breaking anything that depends on them and also to allow having different sets of packages installed in parallel (e.g., EPICS 3.15 and 7.0 in parallel along with the EPICS modules built for them).

A secondary motivation for API and ABI compatibility is to make the upgrade process easier.  If EPICS and all of the EPICS modules cared about API and ABI compatibility, I suspect they would not break it as often, and I think this would result in an easier time upgrading EPICS and EPICS modules in that I wouldn't have to change as much source code for API changes, and I would have a better chance of avoiding so-called "dependency hell."

Lewis