You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Vahid S Hashemian <va...@us.ibm.com> on 2017/01/09 16:58:36 UTC
[VOTE] KIP-109: Old Consumer Deprecation
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
Re: [VOTE] KIP-109: Old Consumer Deprecation
Posted by Vahid S Hashemian <va...@us.ibm.com>.
Hi Ismael,
Sure, that sounds good to me. Thanks.
--Vahid
From: Ismael Juma <is...@juma.me.uk>
To: dev@kafka.apache.org
Date: 01/10/2017 03:26 AM
Subject: Re: [VOTE] KIP-109: Old Consumer Deprecation
Sent by: ismaelj@gmail.com
Thanks Vahid. 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).
Ismael
On Mon, Jan 9, 2017 at 4:58 PM, 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
>
>
>
Re: [VOTE] KIP-109: Old Consumer Deprecation
Posted by Ismael Juma <is...@juma.me.uk>.
Thanks Vahid. 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).
Ismael
On Mon, Jan 9, 2017 at 4:58 PM, 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
>
>
>
Re: [VOTE] KIP-109: Old Consumer Deprecation
Posted by Vahid S Hashemian <va...@us.ibm.com>.
Sure. The following is the voting outcome. I'll update the KIP too.
Voting on this KIP ends with 3 binding and 1 non-binding +1 votes.
Thanks to everyone who participated in the discussion / voted on this KIP.
The decision was to include it in the release following 0.10.2.0.
Binding votes by:
* Ismeal Juma
* Gwen Shapira
* Jason Gustafson
Non-binding vote by:
* Stevo Slavić
Comments and feedback are still welcome!
--Vahid
From: Gwen Shapira <gw...@confluent.io>
To: dev@kafka.apache.org
Date: 02/06/2017 10:29 PM
Subject: Re: [VOTE] KIP-109: Old Consumer Deprecation
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
<va...@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 <gw...@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ć <ss...@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 <is...@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 <gw...@confluent.io>
>>> > wrote:
>>> > >
>>> > > > +1
>>> > > >
>>> > > > On Mon, Jan 9, 2017 at 8:58 AM, Vahid S Hashemian
>>> > > > <va...@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
Re: [VOTE] KIP-109: Old Consumer Deprecation
Posted by Gwen Shapira <gw...@confluent.io>.
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
<va...@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 <gw...@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ć <ss...@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 <is...@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 <gw...@confluent.io>
>>> > wrote:
>>> > >
>>> > > > +1
>>> > > >
>>> > > > On Mon, Jan 9, 2017 at 8:58 AM, Vahid S Hashemian
>>> > > > <va...@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
Re: [VOTE] KIP-109: Old Consumer Deprecation
Posted by Vahid S Hashemian <va...@us.ibm.com>.
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 <gw...@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ć <ss...@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 <is...@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 <gw...@confluent.io>
>> > wrote:
>> > >
>> > > > +1
>> > > >
>> > > > On Mon, Jan 9, 2017 at 8:58 AM, Vahid S Hashemian
>> > > > <va...@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
Re: [VOTE] KIP-109: Old Consumer Deprecation
Posted by Gwen Shapira <gw...@confluent.io>.
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ć <ss...@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 <is...@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 <gw...@confluent.io>
>> > wrote:
>> > >
>> > > > +1
>> > > >
>> > > > On Mon, Jan 9, 2017 at 8:58 AM, Vahid S Hashemian
>> > > > <va...@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
Re: [VOTE] KIP-109: Old Consumer Deprecation
Posted by Jason Gustafson <ja...@confluent.io>.
+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ć <ss...@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 <is...@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 <gw...@confluent.io>
> > wrote:
> > >
> > > > +1
> > > >
> > > > On Mon, Jan 9, 2017 at 8:58 AM, Vahid S Hashemian
> > > > <va...@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
> > > >
> > >
> >
>
Re: [VOTE] KIP-109: Old Consumer Deprecation
Posted by Stevo Slavić <ss...@gmail.com>.
+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 <is...@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 <ew...@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 <gw...@confluent.io>
> wrote:
> >
> > > +1
> > >
> > > On Mon, Jan 9, 2017 at 8:58 AM, Vahid S Hashemian
> > > <va...@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
> > >
> >
>
Re: [VOTE] KIP-109: Old Consumer Deprecation
Posted by Ismael Juma <is...@juma.me.uk>.
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 <ew...@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 <gw...@confluent.io> wrote:
>
> > +1
> >
> > On Mon, Jan 9, 2017 at 8:58 AM, Vahid S Hashemian
> > <va...@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
> >
>
Re: [VOTE] KIP-109: Old Consumer Deprecation
Posted by Ewen Cheslack-Postava <ew...@confluent.io>.
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 <gw...@confluent.io> wrote:
> +1
>
> On Mon, Jan 9, 2017 at 8:58 AM, Vahid S Hashemian
> <va...@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
>
Re: [VOTE] KIP-109: Old Consumer Deprecation
Posted by Gwen Shapira <gw...@confluent.io>.
+1
On Mon, Jan 9, 2017 at 8:58 AM, Vahid S Hashemian
<va...@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