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.
Remember that EPICS is much older than SemVer and tools to do ABI comparisons have only come along fairly recently. We don't have very many EPICS core developers, and the ones we do have all have other responsibilities too. If someone else wants to work with
us and take on the role of ABI monitoring I think we'd be willing to look at changing our development practices, but we are going to need additional resources to be able to promise the kind of ABI compatibility you're wanting.
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.
If you had to choose between more features and ABI compatibility, which would you prefer? This is a version of the old "Cheap, Fast, Good — pick 2" triangle.