Experimental Physics and
| |||||||||||||||||
|
On 1/8/20 4:16 PM, J. Lewis Muir wrote: 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).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. 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.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.) 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.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. 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. 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.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. - Andrew -- Complexity comes for free, Simplicity you have to work for.
| ||||||||||||||||
ANJ, 09 Jan 2020 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |