On Mar 13, 2012, at 9:29 AM, Arvind Prabhakar wrote: > > On Tue, Mar 13, 2012 at 7:53 AM, Ralph Goers <[email protected]> > wrote: >> >> On Mar 12, 2012, at 10:59 PM, Juhani Connolly wrote: >>> >>> While we have added some cool new features, and fixed some bugs, other new >>> ones have appeared and some of the sub-tasks of the original flume-728 task >>> have been left by the wayside. We're talking about putting 1.1.0 out but >>> there's no target for what 1.1.0 is meant to have? I hope we're not heading >>> towards a development style of "release whatever we've done" without a plan. >> >> Software is never perfect. Apache philosophy has always been that it is >> better to release often than constantly be waiting for features or specific >> bug fixes - unless they are determined to be blockers. Users really like >> getting their hands on the software without having to build it. >> >> While I think roadmaps are great as a discussion point, the proof of what is >> needed is what the developers actually write and commit. It doesn't make >> sense to wait for something on the roadmap that no one really wants to >> implement or that users are OK with living without. >> >> That said, every attempt should be made to release software that does what >> it says it does and is reliable. That is why I asked the question about the >> version number. A release with just a number carries certain expectations >> that a release with "beta" in it doesn't have. > > I agree with Ralph's point here. We have had a 1.0.0 alpha release and > what we release right now is going to be more of a beta than anything > else. Primarily because of all the reasons Juhani pointed out - this > release will leave room for improvement. > > +1 on officially labeling 1.1.0-incubating version as a "beta". > > We can continue to have the roadmap discussion and work out the plan > for delivering the in-flight features in 1.2.0 which will should > target to make a stable release.
+1 on a 1.1.0 beta. As long as we put in some critical build and stability fixes for bugs that crept in recently (FLUME-1027 & FLUME-1028), the state of Flume NG today is way better than it was at 1.0.0. I agree with Juhani that we should pick up the discussion about where we are going. After reflecting a bit more on it, I'm not convinced that it would be effective to try and lock in what should go in the "next release" though, because releasing on a short schedule, say once a month, helps keep us honest about where we are and helps us eat the elephant one byte at a time (har har). Ralph you are right, few people want to build from source and deploy that to production. It's a lot of commitment to knowing what's going on with the state of the source tree. Still, I think it is important for Flume for the developers to stay in sync with what each other are doing and try to move in the same direction. I think we should also collaborate on solving shared pain points of interest (e.g. FileChannel) if it's practical to work together on it. Best, Mike
