flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Metzger <rmetz...@apache.org>
Subject Re: [DISCUSSION] Release current master as 0.9.1 (mod few changes)
Date Wed, 26 Aug 2015 10:07:25 GMT
I'm against using the current master for 0.9.1.
It contains too many changes, posing the risk of changing APIs/semantics/...
I agree with Max that there was no consensus or discussion regarding the
scope of the 0.10 release.

How about we release a 0.9.1 version containing all fixes we can easily
apply to the release-0.9 branch and a 0.10-milestone1 off our current
"master".

Ideally we release 0.10-milestone1 before merging new major changes such as
master high availablilty.





On Wed, Aug 26, 2015 at 11:42 AM, Maximilian Michels <mxm@apache.org> wrote:

> I might not have made my point clear but I wrote:
>
> >However, I can see applying a subset of carefully selected commits from
> the
> >master branch as an option.
>
> And you wrote:
>
> >We can also try and "rebase" a fork of the maser to the "0.9" branch,
> where
> >we select something like 70%-80% of the commits (all fixes and reworks)
> and
> >drop the API beaking ones.
>
> So we essentially agree on this issue. Or not?
>
> Forking the entire branch is not an option for me for the 0.9.1
> release. I think we could do an 0.10 release since we never decided
> 0.10 would freeze the streaming API. These are just statements by
> individual committers and do not represent the community's opinion.
>
>
>
> On Wed, Aug 26, 2015 at 11:12 AM, Stephan Ewen <sewen@apache.org> wrote:
> > @mxm: I know the textbook theory ;-)
> >
> > The whole point here is that it is not possible to do that. Fixes and
> major
> > reworks changes go together so tightly that you can get none or both.
> >
> > Not having the fixes voids the purpose of the bugfix release. Having both
> > means it is hard to guarantee all changes are non-breaking.
> >
> > On Wed, Aug 26, 2015 at 11:08 AM, Maximilian Michels <mxm@apache.org>
> wrote:
> >
> >> A bugfix release should not be forked from the current master. It is
> >> very hard to asses whether we don't break the API because there are
> >> many small fixes going in almost daily. However, I can see applying a
> >> subset of carefully selected commits from the master branch as an
> >> option. Only those commits should be cherry-picked which are required
> >> to fix the streaming issues.
> >>
> >> On Wed, Aug 26, 2015 at 10:50 AM, Stephan Ewen <sewen@apache.org>
> wrote:
> >> > @Aljoscha: Correct me if I am wrong, but did the change actually break
> >> > anything user facing?
> >> >
> >> > The source function and source context interface look still the same.
> The
> >> > underlying changes to introduce watermarks should not be visible to
> any
> >> > user anyways at this point (if we remove the additional source
> contexts)
> >> >
> >> > On Wed, Aug 26, 2015 at 10:46 AM, Stephan Ewen <sewen@apache.org>
> wrote:
> >> >
> >> >> The timestamp thing is one of the biggest questions.
> >> >>
> >> >> The fixes that came as part of that pull request are crucial and
> hard to
> >> >> pull out of the change.
> >> >>
> >> >> On Wed, Aug 26, 2015 at 10:44 AM, Aljoscha Krettek <
> aljoscha@apache.org
> >> >
> >> >> wrote:
> >> >>
> >> >>> I don't think we had to many API breaking changes. If everyone
was
> >> >>> careful,
> >> >>> maybe these are even it:
> >> >>> https://cwiki.apache.org/confluence/display/FLINK/0.10+Release
> >> >>>
> >> >>> I added my breaking stuff there. And of course the whole Timestamp
> >> thing
> >> >>> is
> >> >>> a change, but it does not affect the normal source interface.
> >> >>>
> >> >>> On Wed, 26 Aug 2015 at 10:24 Stephan Ewen <sewen@apache.org>
wrote:
> >> >>>
> >> >>> > We can also try and "rebase" a fork of the maser to the "0.9"
> branch,
> >> >>> where
> >> >>> > we select something like 70%-80% of the commits (all fixes
and
> >> reworks)
> >> >>> and
> >> >>> > drop the API beaking ones.
> >> >>> >
> >> >>> > Let me try this and see how feasible it is...
> >> >>> >
> >> >>> > On Wed, Aug 26, 2015 at 9:52 AM, Ufuk Celebi <uce@apache.org>
> wrote:
> >> >>> >
> >> >>> > > I think you are the best one to assess this at the moment
since
> you
> >> >>> are
> >> >>> > > doing the hard work of back porting the changes.
> >> >>> > >
> >> >>> > > Are you suggesting this, because it is a) less
> error-prone/easier
> >> or
> >> >>> b)
> >> >>> > > faster to do?
> >> >>> > >
> >> >>> > > For those that haven't followed the discussion: Stephan
is back
> >> >>> porting
> >> >>> > > fixes for the streaming fault tolerance. There is consensus
that
> >> the
> >> >>> > > changes need to be in the bug fix release. So it's definitely
> not
> >> an
> >> >>> > option
> >> >>> > > to skip it.
> >> >>> > >
> >> >>> > > In general I would like to keep our established process
of back
> >> >>> porting
> >> >>> > > fixes to the release-X branch. But given the importance
of the
> to
> >> be
> >> >>> back
> >> >>> > > ported fixes and the difficulty of back porting it, I
think your
> >> >>> > suggestion
> >> >>> > > is reasonable. We have to be very careful to not change
> behaviour
> >> >>> between
> >> >>> > > minor releases though.
> >> >>> > >
> >> >>> > > We also have to think about the following points if we
fork off
> >> from
> >> >>> > > master:
> >> >>> > > - The startup script behaviour has changed
> >> >>> > > - HA ZooKeeper setup needs to be removed
> >> >>> > >
> >> >>> >
> >> >>>
> >> >>
> >> >>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message