One suggestion for future major release announcements: I propose that we add a list of deprecated / breaking API changes in the announcement of major releases. Although @PublicEnvolving API is not guaranteed to not change across releases, it would still be nice that there’s a proper announcement when changing or deprecating them. Ideally, to avoid collecting the whole list during the release which most likely wouldn’t work, we can collect this list on the wiki during the development cycle.
On 31 May 2017 at 2:22:34 PM, Robert Metzger (rmetz...@apache.org) wrote: 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. > > >>> > > >> > > >> > > > > >
