Hi Jan, The issue was discussed on the release voting thread and there seems to be an agreement in the community that it may not be worth holding the release to include Java 8 support since
1.) Among most of the users, as evident on the vote thread, very few are running Java 8 in dev and test environment and even fewer are running it in production. 2.) The changes that seem to fix the test failures involves moving to a very new release of few libraries which are tightly integrated with Drill's core functionality and hence we would like to test these a bit more before merging in to a release. 3.) With our goal to have shorter and more frequent (monthly) releases, we try to be little judicious with picking what issue could have a wider user impact and should be fixed immediately, vs something which affects a very small percentage of use cases. 4.) And lastly, as Julian mentioned on the thread that the set of fixes might not be complete yet, I think we need more time before we can merge these changes in to a release with confidence to support a new platform. I hope this persuades you to reconsider your position on this release candidate. Regards, aditya... On Tue, Oct 7, 2014 at 12:02 PM, Ted Dunning <ted.dunn...@gmail.com> wrote: > On Tue, Oct 7, 2014 at 8:41 AM, jan i <j...@apache.org> wrote: > > > It seems (from the vote thread) you already have solved the problem, but > > dont want to wait for a respin, can you please at least explain why the > > project is under such a time constraint, that 72 hours is too long to > wait > > to make good quality. > > > > You have to make a cut somewhere. > > There are always a number of very small, low priority bugs and platform > issues in any release. Drill is now on a monthly release cycle so triaging > a minor bug as something that doesn't stop shipping has very little > down-side. > > On the other hand, delaying by 3+ days is more than a 10% delay in the > monthly release. > > Your characterization of this issue being a "quality" issue is also a bit > of an over-statement. The problem was that several dependencies worked > differently on Java8 than Java7. The fix involved changing the version of > these dependencies. Changing dependency versions is not a small change and > requires a full QA cycle since it takes serious thought to decide what > impact the version change might have. The best way for that to happen in a > reasonable way is to simply put this fix in the next release. >
