kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gwen Shapira <g...@confluent.io>
Subject Re: [VOTE] KIP-109: Old Consumer Deprecation
Date Tue, 07 Feb 2017 06:29:28 GMT
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
<vahidhashemian@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 <gwen@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 <jason@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ć <sslavic@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 <ismael@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 <
>>> ewen@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 <gwen@confluent.io>
>>> > wrote:
>>> > >
>>> > > > +1
>>> > > >
>>> > > > On Mon, Jan 9, 2017 at 8:58 AM, Vahid S Hashemian
>>> > > > <vahidhashemian@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

Mime
View raw message