Thanks a lot for all your responses on the point Till raised. It seems that we have an agreement to release this RC as Flink 1.3.0. I'll include a note into the release announcement regarding the state descriptor issue.
Thanks also for all the release testing and the votes. +1 votes: - Chesnay - Robert (binding) - jincheng sun - Aljoscha (binding) - Gordon - Greg (binding) That's 6 votes, out of which 3 are binding. Therefore, I'll release RC3 as Flink 1.3.0! On Wed, May 31, 2017 at 2:08 PM, Till Rohrmann <trohrm...@apache.org> wrote: > 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. > > >>> > > >> > > >> > > > > >
