Thanks. Is it worthwhile updating the KIP with the timeline? So
someone like me who is catching up can figure out the status?
On Mon, Feb 6, 2017 at 10:08 PM, Vahid S Hashemian
<vahidhashem...@us.ibm.com> wrote:
> Hi Gwen,
>
> The KIP passed with enough binding votes, but I think not everyone was
> decided on whether it should go into 0.10.2.0 or the following release.
>
> Quoting Ismael on an earlier post in the same thread:
>
> {quote}
> I think there are 2 aspects to this KIP:
>
> 1. Deprecating the old consumers
> 2. When it should be done
>
> I think everyone agrees that we should deprecate it, but there is a
> difference of opinions on the timing. I think it may be best not to rush
> it, so I'm +1 on this for the release after 0.10.2.0 (which means the PR
> could be merged after the 0.10.2 branch is created in a couple of weeks).
> {quote}
>
> --Vahid
>
>
>
>
> From: Gwen Shapira <g...@confluent.io>
> To: dev@kafka.apache.org
> Date: 02/06/2017 07:39 PM
> Subject: Re: [VOTE] KIP-109: Old Consumer Deprecation
>
>
>
> What's the status here? It looks like we voted in favor of deprecating
> in 0.10.2 but the JIRA is open and we rolled out an RC...
> I'm confused :)
>
> On Wed, Jan 11, 2017 at 4:10 PM, Jason Gustafson <ja...@confluent.io>
> wrote:
>> +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
>>> > > >
>>> > >
>>> >
>>>
>
>
>
> --
> Gwen Shapira
> Product Manager | Confluent
> 650.450.2760 | @gwenshap
> Follow us: Twitter | blog
>
>
>
>
>
--
Gwen Shapira
Product Manager | Confluent
650.450.2760 | @gwenshap
Follow us: Twitter | blog
