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

[Ralph Lange via Tech-talk <tech-talk@aps.anl.gov>]

On Wed, 8 Jan 2020 at 23:17, J. Lewis Muir via Tech-talk <tech-talk@aps.anl.gov> wrote:

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