Experimental Physics and
Industrial Control System

"J. Lewis Muir via Tech-talk" <[email protected]> · Thu, 9 Jan 2020 11:45:25 -0600

On 01/09, Ralph Lange via Tech-talk wrote:
> EPICS is less monolithic than it might look. Even the central parts called
> EPICS Base effectively always have been a distribution, i.e. a collection
> of modules - nowadays this shows in the source code structure (and on Linux
> in the library names), traditionally it didn't.
> 
> Are you really calling for the EPICS distribution version to do a <major>
> jump whenever any of its modules does an incompatible API change?

By "EPICS module" I meant a package not part of the EPICS package (e.g,
the modules that are included in synApps [1], the modules that have
repositories in [2], or the modules listed at [3]).  By "EPICS" I meant
the EPICS package (e.g., the 3.15 release series [4]).

So, I'm wishing for the EPICS package to adopt semantic versioning, and
I'm also wishing for each EPICS module to adopt semantic versioning as
well.

As far as the EPICS 7.0 series goes, maybe things are different in
it compared to the 3.15 series, and perhaps this is where things
are getting confused.  I haven't looked closely at the 7.0 series.
Is it somehow split up into things that you might be referring
to as "modules?"  Looking at [5], I see a download link labeled
base-7.0.3.1.tar.gz, so I think that's what I meant by "EPICS."

However, I also see links on the same page to release notes for pvData,
pvAccess, pva2pva, normativeTypes, pvaClient, and pvDatabase.  What are
those?  What are they called?  If they're what you're calling "modules,"
then I think it would be helpful to come up with a different name for
them.  Looking at [6], I see that the C++ implementations of them appear
to be included as Git submodules in what I'm calling the "EPICS" source.
So, given this, I would wish for all of those Git submodules to either
only be released as part of EPICS or to adhere to semantic versioning.
If you're asking whether I'm really calling for the major version of
EPICS to be incremented when any of the Git submodules breaks API or ABI
compatibility, then my answer is yes.

If you're saying that EPICS 7.0 and future release series are
essentially a software collection, then I think that's a big change
compared to all the previous EPICS series.  In that case, if EPICS 7.0
and beyond are just a software collection (kind of like synApps is for
what I have been calling EPICS modules), then I would say that if it's
a package, then yes, I would still wish for it to adhere to semantic
versioning.  That would make it very clear when API and ABI backward
compatibility is being broken.  If the packages in the collection are
breaking API and ABI backward compatibility left and right, then yes,
the collection package is going to end up incrementing its major version
number all the time too.

I would be fine with that, but if everyone hates that, another approach,
if EPICS 7.0 and beyond are just a software collection, is to use an
8-digit date as its version (e.g., 20191101).  This is essentially
equivalent to incrementing the major version in semantic versioning
since you would basically treat that 8-digit date as an integer, and
it would represent the major version, and it would increment for each
release, and it would not allow you to ever release more than one
version in a day.

I'm not quite convinced that EPICS 7.0 and beyond are just a software
collection, though, because if they are, I should be able to install
the packages that make up the collection separately and end up with the
same result.  I haven't looked closely at the EPICS 7.0 series, but
that doesn't appear to be true just looking at [7] which clearly has
source code that is not part of any of the Git submodules.  To make
EPICS 7.0 and beyond truly a collection, there would need to be another
package that I could download for that source code that is not in the
Git submodules.  It could be called epics-base. :-) Or epics-core?  Then
I could install all the packages that make up the collection separately.
I would still wish for the separate packages to adhere to semantic
versioning (as long as they are intended to be released separately as
stand-alone packages).  But my first choice still would be for the
EPICS 7.0 and beyond software collection package to adhere to semantic
versioning.

> Linux distributions certainly don't do this.

They don't?  To me at least some do.  Take RHEL 8, for example.  It has
the concept of compatibility levels and says compatibility level 2 is
the default for packages in RHEL 8 [8]:

  Compatibility level 2

  APIs and ABIs are stable within the lifetime of a single major
  release.  Compatibility level 2 application interfaces will not
  change from minor release to minor release and can be relied upon
  by the application to be stable for the duration of the major
  release.  Compatibility level 2 is the default for packages in Red
  Hat Enterprise Linux 8.  Packages not identified as having another
  compatibility level may be considered compatibility level 2.

Not all of the packages in RHEL 8 are considered to be in compatibility
level 2, but a large number of them are.  And the next major release
after RHEL 8 will be 9.  To me this is the same as incrementing the
major version of the EPICS 7.0 and beyond software collection.

Lewis

[1]: https://www.aps.anl.gov/BCDA/synApps/Included-Modules
[2]: https://github.com/epics-modules
[3]: https://epics.anl.gov/modules/index.php
[4]: https://epics.anl.gov/base/R3-15/index.php
[5]: https://epics.anl.gov/base/R7-0/3.php
[6]: https://git.launchpad.net/epics-base/tree/.gitmodules
[7]: https://git.launchpad.net/epics-base/tree/
[8]: https://access.redhat.com/articles/rhel8-abi-compatibility

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System