EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <2020>  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <2020>  2021  2022  2023  2024 
<== Date ==> <== Thread ==>
Subject: Re: EPICS release series after 7.0: 7.1 or 8.0?
From: "Johnson, Andrew N. via Tech-talk" <[email protected]>
To: "[email protected]" <[email protected]>
Date: Wed, 8 Jan 2020 16:55:29 +0000
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.
Replies:
Re: EPICS release series after 7.0: 7.1 or 8.0? J. Lewis Muir via Tech-talk
Re: EPICS release series after 7.0: 7.1 or 8.0? Wang Xiaoqiang via Tech-talk
References:
EPICS release series after 7.0: 7.1 or 8.0? J. Lewis Muir via Tech-talk
Navigate by Date:
Prev: RE: Ethernet question Mark Rivers via Tech-talk
Next: Re: EPICS release series after 7.0: 7.1 or 8.0? J. Lewis Muir via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <2020>  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: EPICS release series after 7.0: 7.1 or 8.0? Abdalla Ahmad via Tech-talk
Next: Re: EPICS release series after 7.0: 7.1 or 8.0? J. Lewis Muir via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <2020>  2021  2022  2023  2024 
ANJ, 09 Jan 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·