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