Experimental Physics and
Industrial Control System

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:	"J. Lewis Muir" <[email protected]>
Cc:	"[email protected]" <[email protected]>
Date:	Thu, 9 Jan 2020 18:28:05 +0000

I started writing this reply yesterday but I didn't have time to finish it last night, so it's a bit behind some of the more recent conversations, but I'm sending it anyway.

On 1/8/20 4:16 PM, J. Lewis Muir wrote:

OK, thanks.  The concept of semantic versioning in UNIX-like OS shared
libraries has been around a lot longer than the Semantic Versioning
document, and other projects have been committed to maintaining ABI
compatibility since very early days even without tools to detect an
ABI-compatibility break.

In EPICS 7 we do now have separate version numbers for each of the component submodules that make up Base, independent of the EPICS Base version itself. The qsrv module even has its own separate ABI version number (look at the CONFIG_*_VERSION files installed into <top>/cfg). Earlier Base versions used the EPICS Base version number for all shared library versions and weren't useful for ABI compatibility, but we now number each module separately (although some modules build multiple libraries which share a version number). I'm not sure what it would take to morph these into something more semantic, but (if we get some help from those pushing for this) we could try to adopt SemVer for those versions at least (or add a separate ABI version number to the other modules).

Regardless, how much effort do you think this would take?  Or, what do
you envision the effort looking like?  (We can discuss off-list if you
think that would be better.)

Initially someone could review the Merge/Pull Requests for Base and the PVA modules and evaluate the code changes proposed just for ABI breaks. If a similar fix could be implemented without breaking the ABI they might offer guidance on how to do that, and if not they would inform the core group about that so we would at least know. We might then decide to delay merging some sets of changes to try and keep ABI compatibility for some releases.

Also, if EPICS switched to maintaining ABI compatibility, what about
the EPICS modules?  It would certainly be nice if EPICS maintained ABI
compatibility, but it would be even better if the whole community did
the same for all EPICS modules! :-)  But if I'm the only one who thinks
this, maybe it's a losing battle.

I can only answer for what I think the core developers might do for Base itself. I believe there are some in the group who would be keen on the idea. As the guy who ends up doing most of the actual releases I will push back anything that increases my workload at release time, but I wouldn't object if the effort is distributed, automated, done by someone else and/or all happens earlier in the release process. If you want us to adopt this, please show us how.

We do now provide CI scripts for building support modules on Travis and Appveyor; if they could incorporate ABI checking as well that might be a way to encourage the owners of other modules to look at adopting this. I think it's all a matter of how much work is involved.

There are lots of cases where I would choose ABI compatibility, but
of course it all depends.  For me, EPICS is already able to do mostly
everything I need, but I realize that others are really pushing the
envelope, so for them it's probably different.  I still wish for support
for conditional statements in the IOC shell, and the hack of expanding
variables to a comment character doesn't count, but maybe the Lua shell
thing would work, so maybe that wish has been met.  There are other
things too, but I feel that most of them could be done in a way that
doesn't break backward compatibility.

I could probably be persuaded to accept iocsh conditionals if someone offers to work on an implementation. We added error handling recently ("on error ...") for sub-scripts, but we don't have any commands yet that read in and skip future parts of the input stream. That's the part (plus agreeing on the syntax) that I'd be most concerned about.

- Andrew

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

References:: 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? Johnson, Andrew N. via Tech-talk; 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? Johnson, Andrew N. via Tech-talk; Re: EPICS release series after 7.0: 7.1 or 8.0? J. Lewis Muir via Tech-talk

Navigate by Date:: Prev: Re: EPICS release series after 7.0: 7.1 or 8.0? (ABI) Michael Davidsaver via Tech-talk; Next: Re: EPICS release series after 7.0: 7.1 or 8.0? (ABI) 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? J. Lewis Muir via Tech-talk; Next: Re: EPICS release series after 7.0: 7.1 or 8.0? Wang Xiaoqiang 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

· Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System