Most schemas will work fine across any of the recent-ish versions of Daffodil.
The majority of changes to Daffodil in the last handful of versions were bug
fixes and API changes. Few schemas relied on the previous buggy behavior (and
the schemas were changed if they did), and the API changes onl
As work on the VSCode Daffodil extension will soon allow it to support the new
version of Daffodil (and, in fact, multiple versions), is there a sample schema
and data set that can be used to demonstrate the breaking change issue for our
testing? Hopefully, there would also be updated schema th
told that nobody is going to downgrade those so we can see them
or run regression testing on them. They expect this to grow to 600+ DFDL
schemas.
So I think we need to consider backward compatibility more and more heavily
over time. The fact that we've done breaking changes before with suff
toggle flag if we really want to maintain backwards
compatibility with the old broken behavior, and then 4.0.0 can toggle the switch
to the correct behavior.
If we still think this requires a major version bump, I would suggest we just
wait until 4.0.0 with the API, scala 3, and other large b
Plan on a rather large release-note section, perhaps even a whole
daffodil-site page of its own to discuss the changes required to schemas
due to this bug-fix.
This will need a substantial worked example, discussion of the
false-positives problem where malformed data might be masked if a branch
wh
https://issues.apache.org/jira/browse/DAFFODIL-1971
I believe that I have the work for this pretty much wrapped up in this PR
(other than rebasing onto main) - https://github.com/apache/daffodil/pull/987
Before finishing that, I figured it would be worth discussing how these changes
can break e
