Incremental changes are easier to manage and test and easier to back out. 3.7 Bug fixes and performance 3.8 Move to new layering. Owl will moves its usage of layering to new layering and test it. If others are using layering, please chime in. 4.0 Move to new Scala version ...
Sincerely, Harinder Sood Senior Program Manager hs...@owlcyberdefense.com 240 805 4219 owlcyberdefense.com The information contained in this transmission is for the personal and confidential use of the individual or entity to which it is addressed. If the reader is not the intended recipient, you are hereby notified that any review, dissemination, or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify the sender immediately. -----Original Message----- From: Interrante, John A (GE Aerospace, US) <john.interra...@ge.com> Sent: Monday, March 18, 2024 11:49 AM To: dev@daffodil.apache.org Subject: Discuss: Layer changes - 3.7.0 or 4.0.0 ? I'm agreeable with seeing 4.0.0 drop Java 8 support, bump to Scala 2.13, merge sapi and japi into api, change directory / jar names, and remove deprecated parts. I also don't think it's worth supporting both the old and new layer APIs. I haven't developed any layer classes or schemas using layer classes, so I'm agnostic whether to switch to the new layer API in 3.7.0 or 4.0.0. I assume there's a limit to how many breaking changes people using Daffodil can absorb over time and how fast they can keep up with multiple releases so I think it makes sense to pack all breaking changes into a single 4.0.0 release which does all the changes together rather than split some changes into 4.0.x followed by 5.0.x and so on. However, I will note that the list of changes above doesn't sound like 4.0.0 could follow 3.7.0 quickly. Some changes may need considerable time effort (Scala 2.13) and different changes may disrupt each other or break existing tests or schemas so Daffodil developers may need several months for integration and testing to make sure 4.0.0 is stable enough for general release. I think people will be concerned about risk and quality. Few people would be happy if 4.0.0 couldn't support current use cases as well as 3.6.0 and required several 4.x.x bugfix releases before its CLI & unified programmatic API became as good in quality as 3.6.0's CLI & Java & Scala APIs. I would like to see more people share their opinions too. Please weigh in with any concerns about putting any of these changes in 3.7.0 and/or 4.0.0. John -----Original Message----- From: Steve Lawrence <slawre...@apache.org> Sent: Monday, March 18, 2024 4:48 AM To: dev@daffodil.apache.org Subject: EXT: Re: Discuss: Layer changes - 3.7.0 or 4.0.0 ? 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 >
