On 01/08, Johnson, Andrew N. wrote:
> 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.
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? Linux distributions certainly don't do this.
Don't get me wrong - I'm all for semantic versioning. I just don't know it this should even apply to a software collection version number.
Cheers,
~Ralph