+1 from me. I'm in favor of deprecating in 0.10.2 if possible, or in the next release at the latest. As Ewen and Stevo have pointed out, it is already effectively deprecated.
-Jason On Wed, Jan 11, 2017 at 4:01 PM, Stevo Slavić <ssla...@gmail.com> wrote: > +1 (non-binding) and for deprecating it ASAP. It's already actually > deprecated, not supported, new features and bug fixes end up only in new > clients API, so would be fair to communicate clearly to users in old > consumer API that it's deprecated, it's further or new use is discouraged > and if one still continues to or especially decides to starts using it that > you're using it at your own risk. Deprecation is just recommendation. > > Wish SimpleConsumer was never part of public API. > > On Thu, Jan 12, 2017 at 12:24 AM, Ismael Juma <ism...@juma.me.uk> wrote: > > > Ewen, > > > > I think a policy of giving it a minimum of one year between deprecation > and > > removal for this case seems reasonable. > > > > Ismael > > > > On Wed, Jan 11, 2017 at 5:45 AM, Ewen Cheslack-Postava < > e...@confluent.io> > > wrote: > > > > > Ismael, > > > > > > Is that regardless of whether it ends up being a major/minor version? > > i.e. > > > given the way we've phrased (and I think started to follow through on) > > > deprecations, if the next releases were 0.10.3.0 and then 0.11.0.0, the > > > deprecation period would only be one release. That would be a tiny > window > > > for a huge deprecation. If the next release ended up 0.11.0.0, then > we'd > > > wait (presumably multiple releases until) 0.12.0.0 which could be > > something > > > like a year. > > > > > > I think we should deprecate the APIs ASAP since they are effectively > > > unmaintained (or very minimally maintained at best). And I'd actually > > even > > > like to do so in 0.10.2.0. > > > > > > Perhaps we should consider a slightly customized policy instead? Major > > > deprecations like this might require something slightly different. For > > > example, I think a KIP + release notes that explain we're marking the > > > consumer as deprecated now but it will continue to exist for at least 1 > > > year (regardless of release versions) and will be removed in the next > > major > > > release *after* 1 year would give users plenty of warning and not > result > > in > > > any weirdness if a major version bump happens relatively soon. > > > > > > (Sorry to drag this into the VOTE thread... If we can agree on that > > > deprecation/removal schedule, I'd love to still get this in by feature > > > freeze, especially since the patch is presumably trivial.) > > > > > > -Ewen > > > > > > On Tue, Jan 10, 2017 at 11:58 AM, Gwen Shapira <g...@confluent.io> > > wrote: > > > > > > > +1 > > > > > > > > On Mon, Jan 9, 2017 at 8:58 AM, Vahid S Hashemian > > > > <vahidhashem...@us.ibm.com> wrote: > > > > > Happy Monday, > > > > > > > > > > I'd like to thank everyone who participated in the discussion > around > > > this > > > > > KIP and shared their opinion. > > > > > > > > > > The only concern that was raised was not having a defined migration > > > plan > > > > > yet for existing users of the old consumer. > > > > > I hope that responses to this concern (on the discussion thread) > have > > > > been > > > > > satisfactory. > > > > > > > > > > Given the short time we have until the 0.10.2.0 cut-off date I'd > like > > > to > > > > > start voting on this KIP. > > > > > > > > > > KIP: > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > > > > 109%3A+Old+Consumer+Deprecation > > > > > Discussion thread: > > > > > https://www.mail-archive.com/dev@kafka.apache.org/msg63427.html > > > > > > > > > > Thanks. > > > > > --Vahid > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Gwen Shapira > > > > Product Manager | Confluent > > > > 650.450.2760 | @gwenshap > > > > Follow us: Twitter | blog > > > > > > > > > >
