Yes, FLINK-6783 might even have been a release blocker…. It’s a new feature that simply doesn’t work in most cases.
> On 31. May 2017, at 14:51, Timo Walther <twal...@apache.org> wrote: > > We should also include FLINK-6783. It seems that WindowedStream::aggregate is > broken right now. > > > Am 31.05.17 um 14:31 schrieb Timo Walther: >> I merged all Table API related PRs. >> >> I'm also fine with a 1.3.1 release this or next week. >> >> >> Am 31.05.17 um 14:08 schrieb Till Rohrmann: >>> I would be ok to quickly release 1.3.1 once the the respective PRs have >>> been merged. >>> >>> Just for your information, I'm not yet through with the testing of the type >>> serializer upgrade feature, though. >>> >>> Cheers, >>> Till >>> >>> On Wed, May 31, 2017 at 12:14 PM, Stefan Richter < >>> s.rich...@data-artisans.com> wrote: >>> >>>> +1 for releasing now and providing a 1.3.1 release soon. >>>> >>>>> Am 31.05.2017 um 11:02 schrieb Gyula Fóra <gyula.f...@gmail.com>: >>>>> >>>>> Hi All, >>>>> >>>>> I also lean towards getting the release out as soon as possible given >>>> that >>>>> it had been delayed quite a bit and there is no major issue without a >>>>> straightforward workaround (agreeing with Nico and Kostas). I am sure >>>> once >>>>> people will start using the new features we will see more issues that >>>>> should be fixed asap in 1.3.1. >>>>> >>>>> Regarding the critical bug Till had found, we could add a line about it >>>> to >>>>> the release notes so that people don't get blocked by it as there is a >>>>> workaround possible. >>>>> >>>>> Regards, >>>>> Gyula >>>>> >>>>> >>>>> Kostas Kloudas <k.klou...@data-artisans.com> ezt írta (időpont: 2017. >>>> máj. >>>>> 31., Sze, 10:53): >>>>> >>>>>> Hi all, >>>>>> >>>>>> I also tend to agree with the argument that says a release should be out >>>>>> as soon as possible, given that 1) it improves usability/functionality >>>> and >>>>>> 2) at a minimum, it does not include new known bugs. The arguments are >>>>>> more or less aligned with Nico’s response on the matter. >>>>>> >>>>>> Focusing on the bug that spiked the current discussion, I agree with >>>> Till >>>>>> that this is alarming, as it passed all previous testing efforts, but I >>>>>> have to >>>>>> add that if nobody so far encountered it, we could release 1.3 now and >>>> fix >>>>>> it in the upcoming 1.3.1. >>>>>> >>>>>> Kostas >>>>>> >>>>>>> On May 31, 2017, at 10:20 AM, Nico Kruber <n...@data-artisans.com> >>>>>> wrote: >>>>>>> IMHO, any release that improves things and does not break anything is >>>>>> worth >>>>>>> releasing and should not be blocked on bugs that it did not cause. >>>>>>> There will always be a next (minor/major) release that may fix this at >>>> a >>>>>> later >>>>>>> time, given that the time between releases is not too high. >>>>>>> >>>>>>> Consider someone waiting for a bugfix/feature that made it into 1.3.0 >>>>>> who--if >>>>>>> delayed--would have to wait even longer for "his" bugfix/feature. Any >>>> new >>>>>>> bugfixes (and there will always be more) can wait a few more days or >>>>>> even a few >>>>>>> weeks and may be fixed in 1.3.1 or so. >>>>>>> >>>>>>> >>>>>>> Nico >>>>>>> >>>>>>> On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote: >>>>>>>> - Not sure whether it's a good argument to defer fixing major bugs >>>>>> because >>>>>>>> they have not been introduced with 1.3.0. It's actually alarming that >>>>>> these >>>>>>>> things have not been found earlier given that we test our releases >>>>>>>> thoroughly. >>>>>> >>>> >
