Perhaps this is a good point to consider dropping the Recoverable Memory Channel from 1.4 ... since it has been deprecated.
On Wed, May 29, 2013 at 8:49 AM, Ralph Goers <ralph.go...@dslextreme.com>wrote: > I don't consider this a showstopper, but it should be a learning > experience. First, Flume should probably release more often. Second, where > possible deprecate stuff in one release and delete it in the next. > > > Ralph > > On May 28, 2013, at 6:47 AM, Mike Percy wrote: > > > Hmm, I wish we had agreed on the use of those APIs outside the project up > > front. The interfaces log4j2 used to embed Flume were not designed to be > > public. Now that we have a stable API, hopefully log4j2 can have another > > release soon which takes advantage of the embedded agent APIs. > > > > AFAICT it's not going to be straightforward to provide backward > > compatibility with the previous APIs, but I'm willing to be proven > wrong... > > > > Regards, > > Mike > > > > > > > > On Sun, May 26, 2013 at 7:58 AM, Ralph Goers <ralph.go...@dslextreme.com > >wrote: > > > >> The one concern I have is that when adding support for embedded agents > >> some classes were removed. This means if users of Log4j 2 try to use 1.4 > >> they will have problems until it is modified to use Flume 1.4. It would > >> have been nice to have had at least one release where both were present. > >> > >> Ralph > >> > >> On May 22, 2013, at 12:33 AM, Mike Percy wrote: > >> > >>> Hi folks, > >>> We have had over 100 commits since 1.3.1, and a bunch of new features > and > >>> improvements including a Thrift source, much improved ElasticSearch > sink, > >>> support for a new plugins directory and layout, compression support in > >> the > >>> avro sink/source, improved checkpointing in the file channel and more, > >> plus > >>> a lot of bug fixes. > >>> > >>> It seems to me that it's time to start thinking about cutting a 1.4 > >>> release. I would be happy to volunteer to RM the release. Worth noting > >> that > >>> I will be unavailable for the next two weeks... but after that I'd be > >> happy > >>> to pick this up and run with it. That's also a decent amount of time > for > >>> people to get moving on patches and reviews for their favorite > features, > >>> bug fixes, etc. > >>> > >>> If this all sounds OK, I'd like to suggest targeting the last week of > >> June > >>> as a release date. If we can release in time for Hadoop Summit then > that > >>> would be pretty nice. Otherwise, if something comes up and we can't get > >> the > >>> release out that week, let's shoot for the first week of July at the > >> latest. > >>> > >>> Please let me know your thoughts. > >>> > >>> Regards, > >>> Mike > >> > >> > >
