Re: EPICS release series after 7.0: 7.1 or 8.0?

["J. Lewis Muir via Tech-talk" <tech-talk@aps.anl.gov>]

On 01/08, Johnson, Andrew N. wrote:
> Remember that EPICS is much older than SemVer and tools to do ABI
> comparisons have only come along fairly recently. We don't have very
> many EPICS core developers, and the ones we do have all have other
> responsibilities too. If someone else wants to work with us and take on
> the role of ABI monitoring I think we'd be willing to look at changing
> our development practices, but we are going to need additional resources
> to be able to promise the kind of ABI compatibility you're wanting.

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.

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.)

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 try to be forward compatible with our APIs, so older code will
> generally compile and work on newer Base releases. There are times
> when we may break an API but if that happens deliberately we document
> that and show module developers how to change their code so it can be
> compiled against both the old and new APIs. If we do make an API change,
> code using the old API that needs to be modified should always break at
> compile-time, we don't want our users to find out they need to change
> their code after an upgrade when something doesn't work at 2am. We are
> very aware just how much out-of-tree support code is shared between the
> members of the EPICS collaboration, and most of the core developers have
> to maintain some of that either for the community of for their local
> site, so we see maintaining API compatibility as important.

That's positive.  Sorry to press more, but if EPICS adopted a semantic
versioning scheme, you'd have to increment the major version for *any*
incompatible API change.  But I'm sure the developers would make an
effort to avoid that by doing things differently, so it would likely not
be too big of a deal.

> If you had to choose between more features and ABI compatibility, which
> would you prefer? This is a version of the old "Cheap, Fast, Good —
> pick 2" triangle.

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.

Lewis