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 > >> >>> > > > >> >>> > > >> >>> > >> >> > >> >> > >> >
