flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Metzger <rmetz...@apache.org>
Subject Re: [VOTE] Release Apache Flink 1.3.0 (RC3)
Date Thu, 01 Jun 2017 11:40:48 GMT
Hi Timo,

I agree that not having the documentation available for the new features is
not good.
I'll do a pass over all the open documentation PRs and try to merge as many
as possible. If I have the feeling, that we have enough docs, I'll release
1.3.0.
For the table API, I can put a note into the release announcement.



On Wed, May 31, 2017 at 4:52 PM, Timo Walther <twalthr@apache.org> wrote:

> What do you think about waiting with the release announcement for Flink
> 1.3.1 until next week.
>
> IMHO the documentation is not in a good shape for a release annoucement
> right now anyway.
>
> Most of the new features of the Table API are not documented. Docs for
> other features are missing as well or exist in open PR [1].
>
> Regards,
> Timo
>
> [1] https://issues.apache.org/jira/browse/FLINK-6674
>
>
> Am 31.05.17 um 15:03 schrieb Aljoscha Krettek:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message