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

["Johnson, Andrew N. via Tech-talk" <tech-talk@aps.anl.gov>]

Hi Lewis,

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.

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.

It may be more work to rebuild everything (unless you automate; I suggest looking at Sumo), but I don't recommend gambling if you could get phone-calls at 2am when some feature of your beamline stops working after an upgrade.

> 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.
>
> To do the same for EPICS, I'm wondering whether I need to include the
> major and minor version, or just the major version in the package name.
>
> For example, I could have packages named epics3, epics7, and epics8,
> corresponding to 3.15.x, 7.x, and 8.x, but that will only work if the
> 3.15 series is the last supported series for the 3.x major version,
> and the 7.x series are expected to not break backward compatibility
> (i.e., 7.x -> 7.[x+1] does not break backward compatibility).
>
> If the series within the 7.x series (i.e., 7.0, 7.1, 7.2, etc.) will be
> allowed to break backward compatibility and will likely be supported in
> parallel, then I will want to put the major and minor version into the
> package name.  For example, epics315, epics70, epics71, etc.
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...

- Andrew
-- 
Complexity comes for free, Simplicity you have to work for.