Alright, sounds good to me. I'll +1 and merge PR#386 and open a ticket to update it in the future.
- Steve On 6/23/20 8:16 AM, Beckerle, Mike wrote: > I will volunteer to be release manager. Haven't done one lately and I want to > try out the process with new documentation. > > I think SDW is ok for now for the recoverable errors. You are correct that > maybe we should distinguish them at the api & tdml level. But that can be an > improvement done later. > > I think the remaining issue is just closing out the license change. > > ________________________________ > From: Steve Lawrence <slawre...@apache.org> > Sent: Tuesday, June 23, 2020 8:06:49 AM > To: dev@daffodil.apache.org <dev@daffodil.apache.org> > Subject: Re: [DISCUSS] Release Daffodil 2.7.0 > > Reasonable enough. > > I've looked into DAFFODIL-2354 and it doesn't look like it is an easy to > fix. It appears to be caused by marks that aren't directly related to a > point of uncertainty and discarding/resetting newVariableInstance > changes. I'm not sure how often that happens in our code base, but > there's at least one in choice dispatch which causes this problem. > > PR#387 has been merged. > > We still need one more +1 for PR#389. Considering that is a licensing > issue I think it's worth getting in. > > Anyone have any thoughts on PR#386? I had some comments in the review > wondering if an SDW is the right thing for a recoverable error or if we > need a special "RecoverableError" construct. Josh is on vacation this > week so if we do want that change it likely won't get fixed until at > least next week, which feels like an unnecessary delay. > > Perhaps we just wait for PR#389 and call it? > > Would anyone like to be the release manager? I don't mind doing it if no > one else has the time right now. > > - Steve > > On 6/22/20 8:33 PM, Beckerle, Mike wrote: >> I agree we can/should create a 2.7.0 for smooks and others. >> >> If the newVariableInstance bugs are easy, then fixing them is fine, but >> otherwise I would suggest just releasing without those fixed. People have >> been living without newVariableInstance for a long time. >> >> >> >> >> >> ________________________________ >> From: Steve Lawrence <slawre...@apache.org> >> Sent: Friday, June 19, 2020 10:38 AM >> To: dev@daffodil.apache.org <dev@daffodil.apache.org> >> Subject: [DISCUSS] Release Daffodil 2.7.0 >> >> The smooks project (https://smooks.org) is planning a release shortly >> that incorporates Daffodil, but is currently blocked on >> DAFFODIL-2359/PR#387. It's been about 2 months since the last release, >> and a few useful features and bug fixes have been made, so I wanted to >> start a discussion about doing an interim release to the big 3.0.0 that >> is planned but is probably still a ways out. >> >> I suggest that we drop the current Daffodil version in build.sbt to >> 2.7.0 and create a new release and move all resolved issues to a 2.7.0 >> fix version. Any thoughts/objections? >> >> >> There are currently three open pull requests that I think are close to >> being merged and are worth waiting for: >> >> [PR#386] Implemented dfdl:assert failureType="recoverableError" >> >> https://github.com/apache/incubator-daffodil/pull/387 >> >> [PR#387] fixed overflow ArithmeticException when totalDigits >= 10 >> >> https://github.com/apache/incubator-daffodil/pull/387 >> >> [PR#389] Update license information for Scala dependencies to Apache v2 >> >> https://github.com/apache/incubator-daffodil/pull/389 >> >> >> I also think we should at least investigate these two issues: >> >> [DAFFODIL-2354] newVariableInstance leads to mark state exception >> >> https://issues.apache.org/jira/browse/DAFFODIL-2354 >> >> [DAFFODIL-2352] dfdl:newVariableInstance with non-constant defaultValue >> fails >> >> https://issues.apache.org/jira/browse/DAFFODIL-2352 >> >> >> The first issue should almost certainly be fixed since there is no known >> workaround. The second would be nice to be fixed, but has a workaround >> of using setVariable so maybe isn't quite as important. >> >> Thoughts on an interim release, and are there any other open issues that >> should be resolved for such a release? >> >> Also, does anyone want to volunteer to be a release manager? Lola did it >> last time and did a great job at plugging gaps in the release workflow >> documentation, so it should now be a fairly painless process. >> > >
