exclude list of daffodil versions for multi-version builds

[mbeckerle]

Rather than specifying the versions you want, one should exclude the versions you don't want. Then it could always attempt to create versions for every daffodil version that is not intentionally excluded, with some reasonable default that excludes Daffodil prior to say 3.7.0.

Unless a daffodil version needs to be excluded, I think we'd like to not have to update build.sbt files at all when new Daffodil versions are published.

[stevedlawrence]

I think we could do that. A similar option is to have some sort of range using semantic versions, which could also let you exclude things and doesn't rely on choosing a defaults to exclude, for example:

daffodilSemanticCrossVersions = Some(">=3.7.0 <3.9.0 || >=4.0.0")

That said, I kind of don't like the idea of automatically changing cross versions. Otherwise it means a project could publish different versions depending on what version of sbt-daffodil is available at the time of building.

I think the recommend usage wants to use pinned daffodilVersion and pinned crossDaffodilVersions for production level schema projects. And only for schemas that are examples, proof of concepts, etc, then its fine to have versions change to whatever the latest is. And I would suggest in those cases cross versions is probably less important.

So it's either just test with the latest version that's available (and no cross versions), or explicitly pin the versions you care about and supporting new versions requires a change + version bump.

[mbeckerle]

Ok, a good public "production" schema to use to show how to do that is MIL-STD-2045 on github since it really does get used by some non-demonstration schemas.

[Ontiomacer]

Hi, I'm a new contributor. Just checking whether this issue is still unassigned or if anyone is already working on it. If it's available, I'd be happy to take it up.
@stevedlawrence @mbeckerle

[stevedlawrence]

@Ontiomacer, this ticket is unassigned, but I think the decision is not to make the suggested change but instead to update the https://github.com/DFDLSchemas/mil-std-2045/ project to use the new cross versions feature. Unfortunately, we can't really do that until the new version of the sbt-daffodil plugin is released with that feature. So this probably isn't something that can be worked on yet.

I actually probably wouldn't recommend working on sbt-daffodil as your first task with Daffodil. SBT plugins can be quite difficult to develop if you're not already familiar with it. And I think many of the open issues are still open because their requirements aren't fully defined. That said, if you are really interested in daffodil-sbt development, instead daffodil or daffodil-vscode, let us know and we can certainly find something, we might just need to have some discussions on exactly how we want to change things.

Also, note that we do have a list of beginner friendly issues for the daffodil library here: http://s.apache.org/daffodil-beginner-issues

[Ontiomacer]

Hi @stevedlawrence ,

I saw in the JIRA tracker that you recently added beginner-friendly tasks (reference: https://issues.apache.org/jira/browse/DAFFODIL-3000).
I’d like to let you know I’m working on the “Add Ability To Profile Unapplied Data Editor Changes” feature — GitHub issue: apache/daffodil-vscode#1377 and was assigned this issue yesterday on 12/8/25.

I’ve examined the Data Editor code: the unsaved buffer lives in the front-end stores, but the profiling logic currently only profiles the live session (i.e. previously applied edits). To support profiling of unapplied changes, I propose to extend the profiling request to include the pending buffer (or stage it in a temporary session).

Before writing the patch, I’ve posted a plan in the GitHub issue — would appreciate your confirmation or guidance, to ensure alignment with project expectations.

Thank you,
Tejas/Ontiomacer