flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: [RESULT][VOTE] Release Apache Flink 1.3.0 (RC3)
Date Tue, 06 Jun 2017 12:52:51 GMT
+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 <trohrmann@apache.org> wrote:

> +1 for your suggestions Tzu-Li.
>
> On Tue, Jun 6, 2017 at 9:47 AM, Tzu-Li (Gordon) Tai <tzulitai@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 (rmetzger@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 <trohrmann@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.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