Would it make more sense to be able to announce both new clients stable and deprecate both the scala clients at the same time (irrespective of whether that is next release or one after)? Otherwise is an intermediate state where we recommend you get off the scala producer but not the scala consumer a bit awkward? I kind of think it is but don't have a strong feeling either way so I'm +0.
Also what does deprecate mean? Does it mean we announce a schedule for their removal or does it mean we will add the @deprecated annoyance markers or both? It would be nice to avoid the MapReduce api conversion thing where the old api is @deprecated but the new api has a bunch of gaps that render it unusable for a year or so...that was kind of annoying. :-) -Jay On Tue, Feb 23, 2016 at 9:28 AM, Ismael Juma <ism...@juma.me.uk> wrote: > Hi Flavio, > > On Tue, Feb 23, 2016 at 9:23 AM, Flavio Junqueira <f...@apache.org> wrote: > > > Ismael, I'm curious about why you want to deprecate one and not the > other. > > You say that it is premature to deprecate the old scala consumers and I'm > > wondering about the reasoning behind it. > > > > The new Java producer was introduced in 0.8.2 and it's considered > production-ready. The new Java consumer was introduced in 0.9.0.0 and it's > still marked as beta. We would like to have at least one full release cycle > where the new consumer is no longer in beta, before we consider deprecating > the old consumers. Does that make sense? > > Ismael >
