Re: [DISCUSS] Deprecating the old Scala producers for the next release

2016-02-23 Thread Ismael Juma
Hi Andrew, Thanks for your input. On Tue, Feb 23, 2016 at 11:16 AM, Andrew Schofield < andrew_schofield_j...@outlook.com> wrote: > From my point of view, it seems very odd to deprecate the Scala producer > but not the consumer. So, I would vote to deprecate them both in 0.10. > I explained in o

Re: [DISCUSS] Deprecating the old Scala producers for the next release

2016-02-23 Thread Ismael Juma
Hi Flavio, On Tue, Feb 23, 2016 at 10:46 AM, Flavio Junqueira wrote: > It does make sense, thanks for the clarification. If we deprecate the > producer first, does it mean that the following release won't have a scala > producer but will have a scala consumer? Actually I should have asked this >

Re: [DISCUSS] Deprecating the old Scala producers for the next release

2016-02-23 Thread Ismael Juma
Hi Jay, Comments inline. On Tue, Feb 23, 2016 at 10:38 AM, Jay Kreps wrote: > 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)? I agree that there are b

RE: [DISCUSS] Deprecating the old Scala producers for the next release

2016-02-23 Thread Andrew Schofield
with deprecation annotations. It's just a marker that they're now living on borrowed time. * Remove the ability to connect from these deprecated clients two releases later - so I mean 0.12, not 0.10.0.2. Andrew Schofield -------- > Subject: Re: [DISCUSS] Deprec

Re: [DISCUSS] Deprecating the old Scala producers for the next release

2016-02-23 Thread Flavio Junqueira
It does make sense, thanks for the clarification. If we deprecate the producer first, does it mean that the following release won't have a scala producer but will have a scala consumer? Actually I should have asked this question first: what's the deprecation path precisely? -Flavio > On 23 Feb

Re: [DISCUSS] Deprecating the old Scala producers for the next release

2016-02-23 Thread Jay Kreps
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

Re: [DISCUSS] Deprecating the old Scala producers for the next release

2016-02-23 Thread Ismael Juma
Hi Flavio, On Tue, Feb 23, 2016 at 9:23 AM, Flavio Junqueira 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 int

Re: [DISCUSS] Deprecating the old Scala producers for the next release

2016-02-23 Thread Flavio Junqueira
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. -Flavio > On 22 Feb 2016, at 17:36, Ismael Juma wrote: > > Hi all, > > The new Java producer was intro

Re: [DISCUSS] Deprecating the old Scala producers for the next release

2016-02-23 Thread Ismael Juma
Thanks Grant. On Tue, Feb 23, 2016 at 8:44 AM, Grant Henke wrote: > +1 > > I had a jira tracking marking both as deprecated. I agree we should wait to > deprecate the old consumer. I changed the existing jira to be for the > producer and created a new jira to track deprecating the the consumer >

Re: [DISCUSS] Deprecating the old Scala producers for the next release

2016-02-23 Thread Grant Henke
+1 I had a jira tracking marking both as deprecated. I agree we should wait to deprecate the old consumer. I changed the existing jira to be for the producer and created a new jira to track deprecating the the consumer sometime in the future (likely in the 0.11 release). - KAFKA-2982: Mark the

Re: [DISCUSS] Deprecating the old Scala producers for the next release

2016-02-22 Thread Manikumar Reddy
+1 It will be great If we can completely close below issue. https://issues.apache.org/jira/browse/KAFKA-1843 On Tue, Feb 23, 2016 at 3:25 AM, Joel Koshy wrote: > +1 > > Thanks for bringing it up > > On Mon, Feb 22, 2016 at 9:36 AM, Ismael Juma wrote: > > > Hi all, > > > > The new Java produc

Re: [DISCUSS] Deprecating the old Scala producers for the next release

2016-02-22 Thread Joel Koshy
+1 Thanks for bringing it up On Mon, Feb 22, 2016 at 9:36 AM, Ismael Juma wrote: > Hi all, > > The new Java producer was introduced in 0.8.2.0 (released in February > 2015). It has become the default implementation for various tools since > 0.9.0.0 (released in October 2015) and it is the only

Re: [DISCUSS] Deprecating the old Scala producers for the next release

2016-02-22 Thread Neha Narkhede
+1 On Mon, Feb 22, 2016 at 1:25 PM, Guozhang Wang wrote: > +1. I feel it is the right time to do so in 0.10.0.0. > > On Tue, Feb 23, 2016 at 1:58 AM, Becket Qin wrote: > > > +1 on deprecating old producer. > > > > On Mon, Feb 22, 2016 at 9:36 AM, Ismael Juma wrote: > > > > > Hi all, > > > > >

Re: [DISCUSS] Deprecating the old Scala producers for the next release

2016-02-22 Thread Guozhang Wang
+1. I feel it is the right time to do so in 0.10.0.0. On Tue, Feb 23, 2016 at 1:58 AM, Becket Qin wrote: > +1 on deprecating old producer. > > On Mon, Feb 22, 2016 at 9:36 AM, Ismael Juma wrote: > > > Hi all, > > > > The new Java producer was introduced in 0.8.2.0 (released in February > > 2015

Re: [DISCUSS] Deprecating the old Scala producers for the next release

2016-02-22 Thread Becket Qin
+1 on deprecating old producer. On Mon, Feb 22, 2016 at 9:36 AM, Ismael Juma wrote: > Hi all, > > The new Java producer was introduced in 0.8.2.0 (released in February > 2015). It has become the default implementation for various tools since > 0.9.0.0 (released in October 2015) and it is the onl

[DISCUSS] Deprecating the old Scala producers for the next release

2016-02-22 Thread Ismael Juma
Hi all, The new Java producer was introduced in 0.8.2.0 (released in February 2015). It has become the default implementation for various tools since 0.9.0.0 (released in October 2015) and it is the only implementation with support for the security features introduced in 0.9.0.0. Given this, I th