Declare the versioned surface, drop Docker, and cut 1.9.7 - #22
Declare the versioned surface, drop Docker, and cut 1.9.7#22anderslindho wants to merge 3 commits into
Conversation
recsync's integration tests pull ghcr.io/channelfinder/reccaster:master, which is republished on every push to the default branch. Republishing that tag on 2026-08-03 carried the /recsync to /reccaster path rename from 7d12820 and stopped recsync's integration IOC from initialising. Nothing on their side had changed. Discussion on #21 agreed the image does not belong in an EPICS module repository, and that moving the build to recceiver or recsync would recreate the coupling recsync#158 is trying to end.
`5ff76af` adopted Semantic Versioning by linking the spec, but never said what the public interface is, which clause 1 asks for. Without that, it was unclear whether the container image counted, and the path rename inside it did not look like a breaking change to anyone consuming the image. #21 settled that the image is outside the surface. Record the module boundary here so later releases have a rule to apply.
Nothing has been tagged since the split, so the [Unreleased] section has been accumulating without a release to attach it to. Nothing in the versioned surface changed this cycle: no change to `db/` or `reccaster.dbd`, no iocsh function, no soname bump. Cut it as 1.9.7.
|
|
Briefly discussed API and versioning surface of a module (in general) with @simon-ess and @ralphlange yesterday, and they both leaned against DBs/records being considered as part of it. But I also know others that lean the other way. What are your thoughts re this @tynanford @jacomago? I'm inclined to drop the mention of databases (db, not dbd) and similar. |
Which records? All, |
|
I was thinking all. I am thinking about this more generally, not only here for reccaster. |
Not sure I fully understand. The question is if the .db files provided with a module are part of the overal version, so changes in the .db file only would warant a version bump or not? |
|
Correct, @eddybl. You can see I put this in the CHANGELOG in the diff:
and this is what I am changing my mind on. I have heard people argue both directions in the past. |
This I understand. I see the .db file names, and the set of undefined macros in each file as effectively part of a support module's "versioned surface". Certain changes will cause Use of |
5 participants
recsync's integration tests pull
ghcr.io/channelfinder/reccaster:master, which is republished on every push to the default branch. Republishing that tag on 2026-08-03 carried the/recsyncto/reccasterpath rename from7d12820, which stopped recsync's integration IOC from initialising. Nothing on their side had changed.Discussion on #21 settled that the container image is not part of the versioned surface, and that it does not belong in an EPICS module repository. Moving the build to recceiver or recsync would recreate the coupling recsync#158 is trying to end, so this removes
Dockerfile,.dockerignore, and.github/workflows/docker.ymlinstead. Sites building the module from source are unaffected; downstream consumers of the image will need to decouple on their side.5ff76afadopted Semantic Versioning by linking the spec, but never said what the public interface is, which clause 1 asks for. This records the module boundary inCHANGELOG.md: the databases indb/,reccaster.dbd, the iocsh functions the module registers, the library soname, and any headers it installs. The wire protocol is left out: it is shared with other implementations, and this repository cannot version it alone.This also cuts the accumulated
[Unreleased]entries as 1.9.7 and adds the compare links. Nothing in the versioned surface changed this cycle, so the release is a patch rather than a minor or major bump.recsync#173 asked for a versioned image to pin; once this lands that path is gone and the remaining work is decoupling on the recsync side (recsync#158).