I am a bit skeptical about this proposal. A bug fix release should not change the interface and semantics of the API. It might be possible to catch the interface changes, but it will be really hard to ensure that the semantics are not touched.
I see that there are many important fixes in the current master, but I think it is not a good idea to sacrifice API stability for fixes in a minor release. If we can ensure that the API interface and semantics remain stable, I would be OK with using the master. Even though it does not help with the current issue, we should pay more attention to backporting fixes in the future. 2015-08-26 10:24 GMT+02:00 Stephan Ewen <se...@apache.org>: > 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 > > >
