I am +1 for this idea.
- Henry On Wed, Aug 26, 2015 at 3:07 AM, Robert Metzger <rmetz...@apache.org> wrote: > 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 <m...@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 <se...@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 <m...@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 <se...@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 <se...@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 < >> aljos...@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 <se...@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 <u...@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 >> >> >>> > > >> >> >>> > >> >> >>> >> >> >> >> >> >> >> >> >>
