flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aljoscha Krettek <aljos...@apache.org>
Subject Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Date Wed, 31 May 2017 13:03:20 GMT
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 <twalthr@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.richter@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.fora@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.kloudas@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 <nico@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.
>>>>>> 
>>>> 
> 


Mime
View raw message