I think the compelling argument to get the layers stuff into 3.7.0 is that we don't want any more layers built using 3.6.0-and-prior APIs.
I tend to agree we should not make the next release 4.0.0 because we have other things to get into that release, and the layers stuff is not an official part of DFDL even if it is a practical necessity for many schemas. The easiest way to make-whole the current layer users is just to convert the layers that exist, making new versions of them for Daffodil 3.7.0. I am certainly more than happy to help people do that. I know Owl Cyber has perhaps 6 project-specific layers written. It's quite easy to convert them all, and that's easier than dealing with co-existence. Truly nothing has come up about layers on our mailing lists that I recall, excepting a long time ago someone outside of our core project team created the first version of the byte-swap layer. But that's now a Daffodil built-in layer, and so other than converting the dfdlx layer-related properties from old-to-new, should still work the same. The risk is only that users can't upgrade as easily to 3.7.0. But arguably this is no different than the upgrade where the package names all changes to make OGSI components possible. Perhaps easier. On Mon, Mar 18, 2024 at 4:48 AM Steve Lawrence <slawre...@apache.org> wrote: > I don't think we should make our next release 4.0.0. There's a handful of > changes that have been discussed that probably require a major version > bump > (e.g. drop Java 8 support, bump to Scala 2.13, merge sapi and japi into > api, > change directory structures/jar names, remove deprecated > functions/properties), > I imagine we want to do all that kind of stuff in 4.0.0. And we are about > due > for another release and I don't think we can get all of this in a short > amount > of time to turn 3.7.0 into 4.0.0. > > I'm not sure if it's worth trying to support both APIs. Sounds like it > will be > pretty complicated since the two APIs are so different. > > I think it comes down to whether or not we can comfortably claim the old > layer > API was experimental and if we can claim transitioning to the new API is a > relatively minor change. Personally, I think we can, but if we want to > play it > safe and go strictly by semantic versioning we should delay until 4.0.0 > and plan > for that to be the next release. Maybe we can only focus on those changes > for > the next release and get 4.0.0 out relatively soon after 3.7.0. > > > > > On 2024-03-16 07:40 PM, Mike Beckerle wrote: > > Separate from the pull request review, I want to discuss whether these > > layer changes, which are really a more or less rewrite of the system go > > > > * in 3.7.0, > > * delay them to 4.0.0 > > > > or come up with some co-existence strategy so they can be added to 3.7.0 > > without displacing the existing stuff. > > > > I thought about trying to recast the existing layer stuff in terms of the > > new stuff, and it's hard work. Functional equivalence, bug for bug, would > > be impossible. > > > > Another possible trick is to just add the new stuff... using new package > > names, and separate grammar classes, parser, unparser, etc. In theory the > > two implementations, old and this new one, could co-exist for a release. > > > > Another thought is to just punt on 3.7.0, and renumber so our next > release > > is 4.0.0, where we're allowed more to break things and not be backward > > compatible. > > > > Thoughts on this? > > > > Mike Beckerle > > Apache Daffodil PMC | daffodil.apache.org > > OGF DFDL Workgroup Co-Chair | > www.ogf.org/ogf/doku.php/standards/dfdl/dfdl > > Owl Cyber Defense | www.owlcyberdefense.com > > > >
