+1 bq. we can collect this list on the wiki
Or utilize the Release Note field of JIRA for each such change. On Tue, Jun 6, 2017 at 5:45 AM, Till Rohrmann <trohrm...@apache.org> wrote: > +1 for your suggestions Tzu-Li. > > On Tue, Jun 6, 2017 at 9:47 AM, Tzu-Li (Gordon) Tai <tzuli...@apache.org> > wrote: > > > 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. > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > > >
