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 <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.
