Experimental Physics and
Industrial Control System

"J. Lewis Muir via Tech-talk" <[email protected]> · Wed, 8 Jan 2020 12:21:12 -0600

On 01/08, Johnson, Andrew N. via Tech-talk wrote:
> On 1/7/20 5:01 PM, J. Lewis Muir via Tech-talk wrote:
> > What is the planned EPICS release series after 7.0?  Will it be 7.1 or
> > 8.0?  If it will be 7.1, is the idea that it would be like the 3.11,
> > 3.12, 3.13, 3.14, and 3.15 series where a change in the minor number (in
> > a <major>.<minor>.<patch> versioning scheme) allows breaking backward
> > compatibility?
> 
> The next series will be 7.1. The current plan is that it will require
> at least C++11 support from the OS, so it won't build against VxWorks 6
> or with older MS Visual Studio compilers. We don't have a branch for it
> or a timetable for any releases yet though, so don't expect it anytime
> soon.

OK, thanks for the explanation!

> I'm not sure what you mean by backward compatibility. The EPICS version
> numbers don't follow the principles of Semantic Versioning, we generally
> pick the next number based on what kinds of changes have been included:
> bug fixes and minor enhancements; new features that may require
> modifying clients or IOCs; or major compatibility breaks, dropping
> architectures etc.
>
> EPICS has never promised binary compatibility between releases, no
> matter what the version number change has been, so you should always
> rebuild everything downstream from source code after upgrading Base to
> a new version. We don't have the resources to do compatibility testing
> between binary versions, and we don't generally worry about whether
> changes will break the ABI when making them. For example, in the latest
> Base-3.15.7 and EPICS 7.0.3.1 releases the fields of some of the record
> types were moved around while adding record reference documentation
> to the dbd files, so any external device support built using earlier
> versions would use the wrong field offsets when accessing the record
> field structures.

Wow!  Didn't know that.  So, for even the least significant version
number increment in an EPICS release (e.g., EPICS 3.15.6 -> 3.15.7),
it could be the equivalent of a major version increment in the
Semantic Versioning scheme of <major>.<minor>.<patch>.  That's really
disappointing.

What about API compatibility (i.e., source code compatibility)?  Does
EPICS promise any API compatibility between releases, and if so, what?

> > I'm wishing to plan for how I name EPICS packages that I install, and
> > I want to name them so that they include part of the version in the
> > package name so that I can install them in parallel (i.e., side by
> > side).  This is similar to wanting to install both a Python 2 and 3
> > package and naming them python2 and python3, respectively, so that they
> > can both be installed at the same time without conflicting with each
> > other.
> 
> Given what I said above you should probably include the full EPICS
> version number. However for any support module that is downstream of
> Asyn you'd need to include both the Base and Asyn version numbers in the
> names for those packaged modules, and unfortunately this could generate
> a bit of a combinatorial explosion. EPICS doesn't really make packaging
> binaries easy...

Understood.  Yes, since every release, even an increment of the least
significant version number, could break ABI compatibility, there would
be no choice but to include the full version in the package name.
The UNIX-like concept of shared libraries and being able to update
them independently as long as backward compatibility is maintained is
completely lost on EPICS.

Thanks for your reply!

Lewis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System