Experimental Physics and Industrial Control System
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