You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Guozhang Wang <wa...@gmail.com> on 2016/11/23 19:58:50 UTC
[DISCUSS] 0.10.1.1 Plan
Hi everyone,
We have resolved 15 JIRAs including a few critical bugs in the 0.10.1
branch since 0.10.1.0 was released so I'd like to propose to release
0.10.1.1 soon:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20KAFKA%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC
There are still a few outstanding issues that are not unresolved and have
0.10.1.1 as the target version:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC
Once we have resolved these issues I will start the release process.
--
-- Guozhang
Re: [DISCUSS] 0.10.1.1 Plan
Posted by "Matthias J. Sax" <ma...@confluent.io>.
The commit you mentioned was corrupted and corrected via
https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=cc62b4f844ca16eee974e75b736af87b7532de0d
The code change got reverted.
-Matthias
On 11/29/16 1:35 PM, Ignacio Solis wrote:
> Sorry, that was a hasty reply. There are also various logging things that
> change format. This could break parsers.
>
> None of them are important, my only argument is that the final keyword
> removal is not important either.
>
> Nacho
>
>
> On Tue, Nov 29, 2016 at 1:25 PM, Ignacio Solis <is...@igso.net> wrote:
>
>> https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=
>> 10cfc1628df024f7596d3af5c168fa90f59035ca
>>
>> On Tue, Nov 29, 2016 at 1:24 PM, Ismael Juma <is...@juma.me.uk> wrote:
>>
>>> Which changes break compatibility in the 0.10.1 branch? It would be good
>>> to
>>> fix before the release goes out.
>>>
>>> Ismael
>>>
>>> On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
>>>
>>>> Some of the changes in the 0.10.1 branch already are not bug fixes. Some
>>>> break compatibility.
>>>>
>>>> Having said that, at this level we should maintain a stable API and
>>> leave
>>>> any changes for real version bumps. This should be only a bugfix
>>> release.
>>>>
>>>> Nacho
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <is...@juma.me.uk> wrote:
>>>>
>>>>> I disagree, but let's discuss it another time and in a separate
>>> thread.
>>>> :)
>>>>>
>>>>> Ismael
>>>>>
>>>>> On Tue, Nov 29, 2016 at 4:30 PM, radai <ra...@gmail.com>
>>>> wrote:
>>>>>
>>>>>> designing kafka code for stable extensibility is a worthy and noble
>>>>> cause.
>>>>>> however, seeing as there are no such derivatives out in the wild
>>> yet i
>>>>>> think investing the effort right now is a bit premature from kafka's
>>>> pov.
>>>>>> I think its enough simply not to purposefully prevent such
>>> extensions.
>>>>>>
>>>>>> On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <is...@juma.me.uk>
>>>> wrote:
>>>>>>
>>>>>>> On Sat, Nov 26, 2016 at 11:08 PM, radai <
>>> radai.rosenblatt@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> "compatibility guarantees that are expected by people who
>>> subclass
>>>>>> these
>>>>>>>> classes"
>>>>>>>>
>>>>>>>> sorry if this is not the best thread for this discussion, but I
>>>> just
>>>>>>> wanted
>>>>>>>> to pop in and say that since any subclassing of these will
>>>> obviously
>>>>>> not
>>>>>>> be
>>>>>>>> done within the kafka codebase - what guarantees are needed?
>>>>>>>>
>>>>>>>
>>>>>>> I elaborated a little in my other message in this thread. A simple
>>>> and
>>>>>>> somewhat contrived example: `ConsumerRecord.toString` calls the
>>>> `topic`
>>>>>>> method. Someone overrides the `topic` method and it all works as
>>>>>> expected.
>>>>>>> In a subsequent release, we change `toString` to use the field
>>>> directly
>>>>>>> (like it's done for other fields like `key` and `value`) and it
>>> will
>>>>>> break
>>>>>>> `toString` for this user. One may wonder: why would one override a
>>>>> method
>>>>>>> like `topic`? That is a good question, but part of the exercise is
>>>>>> deciding
>>>>>>> how we approach these issues. We could make the methods final and
>>>>>> eliminate
>>>>>>> the possibility, we could document it so that users can choose to
>>> do
>>>>>> weird
>>>>>>> things if they want, etc.
>>>>>>>
>>>>>>> Another thing that is usually good to think about is the
>>> expectation
>>>>> for
>>>>>>> `equals` and `hashCode`. What if subclasses implement them to have
>>>>> value
>>>>>>> semantics instead of identity semantics. Is that OK or would it
>>> break
>>>>>>> things?
>>>>>>>
>>>>>>> Designing for implementation inheritance is generally complex
>>>> although
>>>>>> for
>>>>>>> simple "record" like classes, it can be easier by following a few
>>>>>>> guidelines.
>>>>>>>
>>>>>>> Ismael
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Nacho - Ignacio Solis - isolis@igso.net
>>>>
>>>
>>
>>
>>
>> --
>> Nacho - Ignacio Solis - isolis@igso.net
>>
>
>
>
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Guozhang Wang <wa...@gmail.com>.
@Bernard Leach
That sounds good, we can consider adding a kafka_2.12-0.10.1.1-beta.tgz
into maven for Scala community to test it out.
Guozhang
On Tue, Nov 29, 2016 at 10:01 PM, Bernard Leach <le...@bouncycastle.org>
wrote:
> Hi Guozhang,
>
> My suggestion was to not add kafka_2.12-0.10.1.0.tgz to downloads.html but
> to still run the build to generate the maven artefacts for 2.12 and still
> publish those to maven central. That would allow projects with binary
> dependencies on kafka to obtain the required jars but hide away the tgz so
> as not to imply that it is suitable for production use. Alternatively just
> do the regular release process and mark it as beta on the downloads page.
> Either way you’ll get more exposure and testing of the 2.12 version which
> you won’t get via SNAPSHOTs from the trunk.,
>
> cheers,
> bern
>
> > On 30 Nov 2016, at 16:52, Guozhang Wang <wa...@gmail.com> wrote:
> >
> > @Ignacio Solis
> >
> > The commit you mentioned was not intended for 0.10.1 but only for trunk
> > (and there is a related KIP for this API change), but mistakenly gets
> > leaked in and was already reverted.
> >
> > @Bernard Leach
> >
> > Could you elaborate on "instead simply publish the artifacts to maven
> > central"? Currently the Kafka release is already through maven and we do
> > not yet have kafka_2.12-0.10.1.0.tgz for binary.
> >
> > https://kafka.apache.org/downloads.html
> >
> > On Tue, Nov 29, 2016 at 5:40 PM, Gwen Shapira <gw...@confluent.io> wrote:
> >
> >> Sorry for my misunderstanding, I assumed the request to include the
> >> keyword removal came from you.
> >>
> >> And it is always good to know what versions LinkedIn are running, you
> >> guys always serve as somewhat of a gold standard to the community :)
> >>
> >> On Tue, Nov 29, 2016 at 5:32 PM, Ignacio Solis <is...@igso.net> wrote:
> >>> I don't think anybody from LinkedIn asked for features on this release.
> >> We
> >>> just jumped in at the discussion of including a patch which was not a
> bug
> >>> fix and whether it mattered.
> >>>
> >>> Having said that, the internal release we're working on came off the
> >> 0.10.1
> >>> branch with a few internal hotfix patches and a few cherry picked
> >> fixes...
> >>> Including the final keyword removal patch.
> >>>
> >>> Nacho
> >>>
> >>>
> >>> On Tue, Nov 29, 2016, 5:15 PM Gwen Shapira <gw...@confluent.io> wrote:
> >>>>
> >>>> btw. is LinkedIn no longer running from trunk? I'm not used to
> >>>> LinkedIn employees requesting specific patches to be included in a
> >>>> bugfix release.
> >>>>
> >>>> Any discussion on the content of any release is obviously welcome, I'm
> >>>> just wondering if there was a change in policy.
> >>>>
> >>>> On Tue, Nov 29, 2016 at 2:17 PM, Ismael Juma <is...@juma.me.uk>
> wrote:
> >>>>> OK, so it seems like there are no changes that break compatibility in
> >>>>> the
> >>>>> 0.10.1 branch since we offer no compatibility guarantees for logging
> >>>>> output. That's good. :)
> >>>>>
> >>>>> About the removal of final, it happened in trunk and it doesn't seem
> >>>>> like
> >>>>> anyone is still asking for it to be included in the 0.10.1 branch so
> >> it
> >>>>> is
> >>>>> indeed not important for this bug fix release (I thought we had
> >>>>> established
> >>>>> that quite a while ago).
> >>>>>
> >>>>> Ismael
> >>>>>
> >>>>> On Tue, Nov 29, 2016 at 9:35 PM, Ignacio Solis <is...@igso.net>
> >> wrote:
> >>>>>
> >>>>>> Sorry, that was a hasty reply. There are also various logging
> things
> >>>>>> that
> >>>>>> change format. This could break parsers.
> >>>>>>
> >>>>>> None of them are important, my only argument is that the final
> >> keyword
> >>>>>> removal is not important either.
> >>>>>>
> >>>>>> Nacho
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Nov 29, 2016 at 1:25 PM, Ignacio Solis <is...@igso.net>
> >> wrote:
> >>>>>>
> >>>>>>> https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=
> >>>>>>> 10cfc1628df024f7596d3af5c168fa90f59035ca
> >>>>>>>
> >>>>>>> On Tue, Nov 29, 2016 at 1:24 PM, Ismael Juma <is...@juma.me.uk>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Which changes break compatibility in the 0.10.1 branch? It would
> >> be
> >>>>>>>> good
> >>>>>>>> to
> >>>>>>>> fix before the release goes out.
> >>>>>>>>
> >>>>>>>> Ismael
> >>>>>>>>
> >>>>>>>> On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
> >>>>>>>>
> >>>>>>>>> Some of the changes in the 0.10.1 branch already are not bug
> >>>>>>>>> fixes.
> >>>>>> Some
> >>>>>>>>> break compatibility.
> >>>>>>>>>
> >>>>>>>>> Having said that, at this level we should maintain a stable API
> >>>>>>>>> and
> >>>>>>>> leave
> >>>>>>>>> any changes for real version bumps. This should be only a
> >> bugfix
> >>>>>>>> release.
> >>>>>>>>>
> >>>>>>>>> Nacho
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <ismael@juma.me.uk
> >>>
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> I disagree, but let's discuss it another time and in a
> >> separate
> >>>>>>>> thread.
> >>>>>>>>> :)
> >>>>>>>>>>
> >>>>>>>>>> Ismael
> >>>>>>>>>>
> >>>>>>>>>> On Tue, Nov 29, 2016 at 4:30 PM, radai
> >>>>>>>>>> <ra...@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> designing kafka code for stable extensibility is a worthy
> >> and
> >>>>>> noble
> >>>>>>>>>> cause.
> >>>>>>>>>>> however, seeing as there are no such derivatives out in the
> >>>>>>>>>>> wild
> >>>>>>>> yet i
> >>>>>>>>>>> think investing the effort right now is a bit premature from
> >>>>>> kafka's
> >>>>>>>>> pov.
> >>>>>>>>>>> I think its enough simply not to purposefully prevent such
> >>>>>>>> extensions.
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma
> >>>>>>>>>>> <is...@juma.me.uk>
> >>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On Sat, Nov 26, 2016 at 11:08 PM, radai <
> >>>>>>>> radai.rosenblatt@gmail.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> "compatibility guarantees that are expected by people
> >> who
> >>>>>>>> subclass
> >>>>>>>>>>> these
> >>>>>>>>>>>>> classes"
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> sorry if this is not the best thread for this
> >> discussion,
> >>>>>>>>>>>>> but
> >>>>>> I
> >>>>>>>>> just
> >>>>>>>>>>>> wanted
> >>>>>>>>>>>>> to pop in and say that since any subclassing of these
> >> will
> >>>>>>>>> obviously
> >>>>>>>>>>> not
> >>>>>>>>>>>> be
> >>>>>>>>>>>>> done within the kafka codebase - what guarantees are
> >>>>>>>>>>>>> needed?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I elaborated a little in my other message in this thread.
> >> A
> >>>>>> simple
> >>>>>>>>> and
> >>>>>>>>>>>> somewhat contrived example: `ConsumerRecord.toString`
> >> calls
> >>>>>>>>>>>> the
> >>>>>>>>> `topic`
> >>>>>>>>>>>> method. Someone overrides the `topic` method and it all
> >>>>>>>>>>>> works as
> >>>>>>>>>>> expected.
> >>>>>>>>>>>> In a subsequent release, we change `toString` to use the
> >>>>>>>>>>>> field
> >>>>>>>>> directly
> >>>>>>>>>>>> (like it's done for other fields like `key` and `value`)
> >> and
> >>>>>>>>>>>> it
> >>>>>>>> will
> >>>>>>>>>>> break
> >>>>>>>>>>>> `toString` for this user. One may wonder: why would one
> >>>>>> override a
> >>>>>>>>>> method
> >>>>>>>>>>>> like `topic`? That is a good question, but part of the
> >>>>>>>>>>>> exercise
> >>>>>> is
> >>>>>>>>>>> deciding
> >>>>>>>>>>>> how we approach these issues. We could make the methods
> >>>>>>>>>>>> final
> >>>>>> and
> >>>>>>>>>>> eliminate
> >>>>>>>>>>>> the possibility, we could document it so that users can
> >>>>>>>>>>>> choose
> >>>>>> to
> >>>>>>>> do
> >>>>>>>>>>> weird
> >>>>>>>>>>>> things if they want, etc.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Another thing that is usually good to think about is the
> >>>>>>>> expectation
> >>>>>>>>>> for
> >>>>>>>>>>>> `equals` and `hashCode`. What if subclasses implement them
> >>>>>>>>>>>> to
> >>>>>> have
> >>>>>>>>>> value
> >>>>>>>>>>>> semantics instead of identity semantics. Is that OK or
> >> would
> >>>>>>>>>>>> it
> >>>>>>>> break
> >>>>>>>>>>>> things?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Designing for implementation inheritance is generally
> >>>>>>>>>>>> complex
> >>>>>>>>> although
> >>>>>>>>>>> for
> >>>>>>>>>>>> simple "record" like classes, it can be easier by
> >> following
> >>>>>>>>>>>> a
> >>>>>> few
> >>>>>>>>>>>> guidelines.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Ismael
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Nacho - Ignacio Solis - isolis@igso.net
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Nacho - Ignacio Solis - isolis@igso.net
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Nacho - Ignacio Solis - isolis@igso.net
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 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
> >>
> >
> >
> >
> > --
> > -- Guozhang
>
>
--
-- Guozhang
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Bernard Leach <le...@bouncycastle.org>.
Hi Guozhang,
My suggestion was to not add kafka_2.12-0.10.1.0.tgz to downloads.html but to still run the build to generate the maven artefacts for 2.12 and still publish those to maven central. That would allow projects with binary dependencies on kafka to obtain the required jars but hide away the tgz so as not to imply that it is suitable for production use. Alternatively just do the regular release process and mark it as beta on the downloads page. Either way you’ll get more exposure and testing of the 2.12 version which you won’t get via SNAPSHOTs from the trunk.,
cheers,
bern
> On 30 Nov 2016, at 16:52, Guozhang Wang <wa...@gmail.com> wrote:
>
> @Ignacio Solis
>
> The commit you mentioned was not intended for 0.10.1 but only for trunk
> (and there is a related KIP for this API change), but mistakenly gets
> leaked in and was already reverted.
>
> @Bernard Leach
>
> Could you elaborate on "instead simply publish the artifacts to maven
> central"? Currently the Kafka release is already through maven and we do
> not yet have kafka_2.12-0.10.1.0.tgz for binary.
>
> https://kafka.apache.org/downloads.html
>
> On Tue, Nov 29, 2016 at 5:40 PM, Gwen Shapira <gw...@confluent.io> wrote:
>
>> Sorry for my misunderstanding, I assumed the request to include the
>> keyword removal came from you.
>>
>> And it is always good to know what versions LinkedIn are running, you
>> guys always serve as somewhat of a gold standard to the community :)
>>
>> On Tue, Nov 29, 2016 at 5:32 PM, Ignacio Solis <is...@igso.net> wrote:
>>> I don't think anybody from LinkedIn asked for features on this release.
>> We
>>> just jumped in at the discussion of including a patch which was not a bug
>>> fix and whether it mattered.
>>>
>>> Having said that, the internal release we're working on came off the
>> 0.10.1
>>> branch with a few internal hotfix patches and a few cherry picked
>> fixes...
>>> Including the final keyword removal patch.
>>>
>>> Nacho
>>>
>>>
>>> On Tue, Nov 29, 2016, 5:15 PM Gwen Shapira <gw...@confluent.io> wrote:
>>>>
>>>> btw. is LinkedIn no longer running from trunk? I'm not used to
>>>> LinkedIn employees requesting specific patches to be included in a
>>>> bugfix release.
>>>>
>>>> Any discussion on the content of any release is obviously welcome, I'm
>>>> just wondering if there was a change in policy.
>>>>
>>>> On Tue, Nov 29, 2016 at 2:17 PM, Ismael Juma <is...@juma.me.uk> wrote:
>>>>> OK, so it seems like there are no changes that break compatibility in
>>>>> the
>>>>> 0.10.1 branch since we offer no compatibility guarantees for logging
>>>>> output. That's good. :)
>>>>>
>>>>> About the removal of final, it happened in trunk and it doesn't seem
>>>>> like
>>>>> anyone is still asking for it to be included in the 0.10.1 branch so
>> it
>>>>> is
>>>>> indeed not important for this bug fix release (I thought we had
>>>>> established
>>>>> that quite a while ago).
>>>>>
>>>>> Ismael
>>>>>
>>>>> On Tue, Nov 29, 2016 at 9:35 PM, Ignacio Solis <is...@igso.net>
>> wrote:
>>>>>
>>>>>> Sorry, that was a hasty reply. There are also various logging things
>>>>>> that
>>>>>> change format. This could break parsers.
>>>>>>
>>>>>> None of them are important, my only argument is that the final
>> keyword
>>>>>> removal is not important either.
>>>>>>
>>>>>> Nacho
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 29, 2016 at 1:25 PM, Ignacio Solis <is...@igso.net>
>> wrote:
>>>>>>
>>>>>>> https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=
>>>>>>> 10cfc1628df024f7596d3af5c168fa90f59035ca
>>>>>>>
>>>>>>> On Tue, Nov 29, 2016 at 1:24 PM, Ismael Juma <is...@juma.me.uk>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Which changes break compatibility in the 0.10.1 branch? It would
>> be
>>>>>>>> good
>>>>>>>> to
>>>>>>>> fix before the release goes out.
>>>>>>>>
>>>>>>>> Ismael
>>>>>>>>
>>>>>>>> On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
>>>>>>>>
>>>>>>>>> Some of the changes in the 0.10.1 branch already are not bug
>>>>>>>>> fixes.
>>>>>> Some
>>>>>>>>> break compatibility.
>>>>>>>>>
>>>>>>>>> Having said that, at this level we should maintain a stable API
>>>>>>>>> and
>>>>>>>> leave
>>>>>>>>> any changes for real version bumps. This should be only a
>> bugfix
>>>>>>>> release.
>>>>>>>>>
>>>>>>>>> Nacho
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <ismael@juma.me.uk
>>>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I disagree, but let's discuss it another time and in a
>> separate
>>>>>>>> thread.
>>>>>>>>> :)
>>>>>>>>>>
>>>>>>>>>> Ismael
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 29, 2016 at 4:30 PM, radai
>>>>>>>>>> <ra...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> designing kafka code for stable extensibility is a worthy
>> and
>>>>>> noble
>>>>>>>>>> cause.
>>>>>>>>>>> however, seeing as there are no such derivatives out in the
>>>>>>>>>>> wild
>>>>>>>> yet i
>>>>>>>>>>> think investing the effort right now is a bit premature from
>>>>>> kafka's
>>>>>>>>> pov.
>>>>>>>>>>> I think its enough simply not to purposefully prevent such
>>>>>>>> extensions.
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma
>>>>>>>>>>> <is...@juma.me.uk>
>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Sat, Nov 26, 2016 at 11:08 PM, radai <
>>>>>>>> radai.rosenblatt@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> "compatibility guarantees that are expected by people
>> who
>>>>>>>> subclass
>>>>>>>>>>> these
>>>>>>>>>>>>> classes"
>>>>>>>>>>>>>
>>>>>>>>>>>>> sorry if this is not the best thread for this
>> discussion,
>>>>>>>>>>>>> but
>>>>>> I
>>>>>>>>> just
>>>>>>>>>>>> wanted
>>>>>>>>>>>>> to pop in and say that since any subclassing of these
>> will
>>>>>>>>> obviously
>>>>>>>>>>> not
>>>>>>>>>>>> be
>>>>>>>>>>>>> done within the kafka codebase - what guarantees are
>>>>>>>>>>>>> needed?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I elaborated a little in my other message in this thread.
>> A
>>>>>> simple
>>>>>>>>> and
>>>>>>>>>>>> somewhat contrived example: `ConsumerRecord.toString`
>> calls
>>>>>>>>>>>> the
>>>>>>>>> `topic`
>>>>>>>>>>>> method. Someone overrides the `topic` method and it all
>>>>>>>>>>>> works as
>>>>>>>>>>> expected.
>>>>>>>>>>>> In a subsequent release, we change `toString` to use the
>>>>>>>>>>>> field
>>>>>>>>> directly
>>>>>>>>>>>> (like it's done for other fields like `key` and `value`)
>> and
>>>>>>>>>>>> it
>>>>>>>> will
>>>>>>>>>>> break
>>>>>>>>>>>> `toString` for this user. One may wonder: why would one
>>>>>> override a
>>>>>>>>>> method
>>>>>>>>>>>> like `topic`? That is a good question, but part of the
>>>>>>>>>>>> exercise
>>>>>> is
>>>>>>>>>>> deciding
>>>>>>>>>>>> how we approach these issues. We could make the methods
>>>>>>>>>>>> final
>>>>>> and
>>>>>>>>>>> eliminate
>>>>>>>>>>>> the possibility, we could document it so that users can
>>>>>>>>>>>> choose
>>>>>> to
>>>>>>>> do
>>>>>>>>>>> weird
>>>>>>>>>>>> things if they want, etc.
>>>>>>>>>>>>
>>>>>>>>>>>> Another thing that is usually good to think about is the
>>>>>>>> expectation
>>>>>>>>>> for
>>>>>>>>>>>> `equals` and `hashCode`. What if subclasses implement them
>>>>>>>>>>>> to
>>>>>> have
>>>>>>>>>> value
>>>>>>>>>>>> semantics instead of identity semantics. Is that OK or
>> would
>>>>>>>>>>>> it
>>>>>>>> break
>>>>>>>>>>>> things?
>>>>>>>>>>>>
>>>>>>>>>>>> Designing for implementation inheritance is generally
>>>>>>>>>>>> complex
>>>>>>>>> although
>>>>>>>>>>> for
>>>>>>>>>>>> simple "record" like classes, it can be easier by
>> following
>>>>>>>>>>>> a
>>>>>> few
>>>>>>>>>>>> guidelines.
>>>>>>>>>>>>
>>>>>>>>>>>> Ismael
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Nacho - Ignacio Solis - isolis@igso.net
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Nacho - Ignacio Solis - isolis@igso.net
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Nacho - Ignacio Solis - isolis@igso.net
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>
>
>
>
> --
> -- Guozhang
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Guozhang Wang <wa...@gmail.com>.
@Ignacio Solis
The commit you mentioned was not intended for 0.10.1 but only for trunk
(and there is a related KIP for this API change), but mistakenly gets
leaked in and was already reverted.
@Bernard Leach
Could you elaborate on "instead simply publish the artifacts to maven
central"? Currently the Kafka release is already through maven and we do
not yet have kafka_2.12-0.10.1.0.tgz for binary.
https://kafka.apache.org/downloads.html
On Tue, Nov 29, 2016 at 5:40 PM, Gwen Shapira <gw...@confluent.io> wrote:
> Sorry for my misunderstanding, I assumed the request to include the
> keyword removal came from you.
>
> And it is always good to know what versions LinkedIn are running, you
> guys always serve as somewhat of a gold standard to the community :)
>
> On Tue, Nov 29, 2016 at 5:32 PM, Ignacio Solis <is...@igso.net> wrote:
> > I don't think anybody from LinkedIn asked for features on this release.
> We
> > just jumped in at the discussion of including a patch which was not a bug
> > fix and whether it mattered.
> >
> > Having said that, the internal release we're working on came off the
> 0.10.1
> > branch with a few internal hotfix patches and a few cherry picked
> fixes...
> > Including the final keyword removal patch.
> >
> > Nacho
> >
> >
> > On Tue, Nov 29, 2016, 5:15 PM Gwen Shapira <gw...@confluent.io> wrote:
> >>
> >> btw. is LinkedIn no longer running from trunk? I'm not used to
> >> LinkedIn employees requesting specific patches to be included in a
> >> bugfix release.
> >>
> >> Any discussion on the content of any release is obviously welcome, I'm
> >> just wondering if there was a change in policy.
> >>
> >> On Tue, Nov 29, 2016 at 2:17 PM, Ismael Juma <is...@juma.me.uk> wrote:
> >> > OK, so it seems like there are no changes that break compatibility in
> >> > the
> >> > 0.10.1 branch since we offer no compatibility guarantees for logging
> >> > output. That's good. :)
> >> >
> >> > About the removal of final, it happened in trunk and it doesn't seem
> >> > like
> >> > anyone is still asking for it to be included in the 0.10.1 branch so
> it
> >> > is
> >> > indeed not important for this bug fix release (I thought we had
> >> > established
> >> > that quite a while ago).
> >> >
> >> > Ismael
> >> >
> >> > On Tue, Nov 29, 2016 at 9:35 PM, Ignacio Solis <is...@igso.net>
> wrote:
> >> >
> >> >> Sorry, that was a hasty reply. There are also various logging things
> >> >> that
> >> >> change format. This could break parsers.
> >> >>
> >> >> None of them are important, my only argument is that the final
> keyword
> >> >> removal is not important either.
> >> >>
> >> >> Nacho
> >> >>
> >> >>
> >> >> On Tue, Nov 29, 2016 at 1:25 PM, Ignacio Solis <is...@igso.net>
> wrote:
> >> >>
> >> >> > https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=
> >> >> > 10cfc1628df024f7596d3af5c168fa90f59035ca
> >> >> >
> >> >> > On Tue, Nov 29, 2016 at 1:24 PM, Ismael Juma <is...@juma.me.uk>
> >> >> > wrote:
> >> >> >
> >> >> >> Which changes break compatibility in the 0.10.1 branch? It would
> be
> >> >> >> good
> >> >> >> to
> >> >> >> fix before the release goes out.
> >> >> >>
> >> >> >> Ismael
> >> >> >>
> >> >> >> On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
> >> >> >>
> >> >> >> > Some of the changes in the 0.10.1 branch already are not bug
> >> >> >> > fixes.
> >> >> Some
> >> >> >> > break compatibility.
> >> >> >> >
> >> >> >> > Having said that, at this level we should maintain a stable API
> >> >> >> > and
> >> >> >> leave
> >> >> >> > any changes for real version bumps. This should be only a
> bugfix
> >> >> >> release.
> >> >> >> >
> >> >> >> > Nacho
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <ismael@juma.me.uk
> >
> >> >> wrote:
> >> >> >> >
> >> >> >> > > I disagree, but let's discuss it another time and in a
> separate
> >> >> >> thread.
> >> >> >> > :)
> >> >> >> > >
> >> >> >> > > Ismael
> >> >> >> > >
> >> >> >> > > On Tue, Nov 29, 2016 at 4:30 PM, radai
> >> >> >> > > <ra...@gmail.com>
> >> >> >> > wrote:
> >> >> >> > >
> >> >> >> > > > designing kafka code for stable extensibility is a worthy
> and
> >> >> noble
> >> >> >> > > cause.
> >> >> >> > > > however, seeing as there are no such derivatives out in the
> >> >> >> > > > wild
> >> >> >> yet i
> >> >> >> > > > think investing the effort right now is a bit premature from
> >> >> kafka's
> >> >> >> > pov.
> >> >> >> > > > I think its enough simply not to purposefully prevent such
> >> >> >> extensions.
> >> >> >> > > >
> >> >> >> > > > On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma
> >> >> >> > > > <is...@juma.me.uk>
> >> >> >> > wrote:
> >> >> >> > > >
> >> >> >> > > > > On Sat, Nov 26, 2016 at 11:08 PM, radai <
> >> >> >> radai.rosenblatt@gmail.com>
> >> >> >> > > > > wrote:
> >> >> >> > > > >
> >> >> >> > > > > > "compatibility guarantees that are expected by people
> who
> >> >> >> subclass
> >> >> >> > > > these
> >> >> >> > > > > > classes"
> >> >> >> > > > > >
> >> >> >> > > > > > sorry if this is not the best thread for this
> discussion,
> >> >> >> > > > > > but
> >> >> I
> >> >> >> > just
> >> >> >> > > > > wanted
> >> >> >> > > > > > to pop in and say that since any subclassing of these
> will
> >> >> >> > obviously
> >> >> >> > > > not
> >> >> >> > > > > be
> >> >> >> > > > > > done within the kafka codebase - what guarantees are
> >> >> >> > > > > > needed?
> >> >> >> > > > > >
> >> >> >> > > > >
> >> >> >> > > > > I elaborated a little in my other message in this thread.
> A
> >> >> simple
> >> >> >> > and
> >> >> >> > > > > somewhat contrived example: `ConsumerRecord.toString`
> calls
> >> >> >> > > > > the
> >> >> >> > `topic`
> >> >> >> > > > > method. Someone overrides the `topic` method and it all
> >> >> >> > > > > works as
> >> >> >> > > > expected.
> >> >> >> > > > > In a subsequent release, we change `toString` to use the
> >> >> >> > > > > field
> >> >> >> > directly
> >> >> >> > > > > (like it's done for other fields like `key` and `value`)
> and
> >> >> >> > > > > it
> >> >> >> will
> >> >> >> > > > break
> >> >> >> > > > > `toString` for this user. One may wonder: why would one
> >> >> override a
> >> >> >> > > method
> >> >> >> > > > > like `topic`? That is a good question, but part of the
> >> >> >> > > > > exercise
> >> >> is
> >> >> >> > > > deciding
> >> >> >> > > > > how we approach these issues. We could make the methods
> >> >> >> > > > > final
> >> >> and
> >> >> >> > > > eliminate
> >> >> >> > > > > the possibility, we could document it so that users can
> >> >> >> > > > > choose
> >> >> to
> >> >> >> do
> >> >> >> > > > weird
> >> >> >> > > > > things if they want, etc.
> >> >> >> > > > >
> >> >> >> > > > > Another thing that is usually good to think about is the
> >> >> >> expectation
> >> >> >> > > for
> >> >> >> > > > > `equals` and `hashCode`. What if subclasses implement them
> >> >> >> > > > > to
> >> >> have
> >> >> >> > > value
> >> >> >> > > > > semantics instead of identity semantics. Is that OK or
> would
> >> >> >> > > > > it
> >> >> >> break
> >> >> >> > > > > things?
> >> >> >> > > > >
> >> >> >> > > > > Designing for implementation inheritance is generally
> >> >> >> > > > > complex
> >> >> >> > although
> >> >> >> > > > for
> >> >> >> > > > > simple "record" like classes, it can be easier by
> following
> >> >> >> > > > > a
> >> >> few
> >> >> >> > > > > guidelines.
> >> >> >> > > > >
> >> >> >> > > > > Ismael
> >> >> >> > > > >
> >> >> >> > > >
> >> >> >> > >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > Nacho - Ignacio Solis - isolis@igso.net
> >> >> >> >
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Nacho - Ignacio Solis - isolis@igso.net
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Nacho - Ignacio Solis - isolis@igso.net
> >> >>
> >>
> >>
> >>
> >> --
> >> 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
>
--
-- Guozhang
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Gwen Shapira <gw...@confluent.io>.
Sorry for my misunderstanding, I assumed the request to include the
keyword removal came from you.
And it is always good to know what versions LinkedIn are running, you
guys always serve as somewhat of a gold standard to the community :)
On Tue, Nov 29, 2016 at 5:32 PM, Ignacio Solis <is...@igso.net> wrote:
> I don't think anybody from LinkedIn asked for features on this release. We
> just jumped in at the discussion of including a patch which was not a bug
> fix and whether it mattered.
>
> Having said that, the internal release we're working on came off the 0.10.1
> branch with a few internal hotfix patches and a few cherry picked fixes...
> Including the final keyword removal patch.
>
> Nacho
>
>
> On Tue, Nov 29, 2016, 5:15 PM Gwen Shapira <gw...@confluent.io> wrote:
>>
>> btw. is LinkedIn no longer running from trunk? I'm not used to
>> LinkedIn employees requesting specific patches to be included in a
>> bugfix release.
>>
>> Any discussion on the content of any release is obviously welcome, I'm
>> just wondering if there was a change in policy.
>>
>> On Tue, Nov 29, 2016 at 2:17 PM, Ismael Juma <is...@juma.me.uk> wrote:
>> > OK, so it seems like there are no changes that break compatibility in
>> > the
>> > 0.10.1 branch since we offer no compatibility guarantees for logging
>> > output. That's good. :)
>> >
>> > About the removal of final, it happened in trunk and it doesn't seem
>> > like
>> > anyone is still asking for it to be included in the 0.10.1 branch so it
>> > is
>> > indeed not important for this bug fix release (I thought we had
>> > established
>> > that quite a while ago).
>> >
>> > Ismael
>> >
>> > On Tue, Nov 29, 2016 at 9:35 PM, Ignacio Solis <is...@igso.net> wrote:
>> >
>> >> Sorry, that was a hasty reply. There are also various logging things
>> >> that
>> >> change format. This could break parsers.
>> >>
>> >> None of them are important, my only argument is that the final keyword
>> >> removal is not important either.
>> >>
>> >> Nacho
>> >>
>> >>
>> >> On Tue, Nov 29, 2016 at 1:25 PM, Ignacio Solis <is...@igso.net> wrote:
>> >>
>> >> > https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=
>> >> > 10cfc1628df024f7596d3af5c168fa90f59035ca
>> >> >
>> >> > On Tue, Nov 29, 2016 at 1:24 PM, Ismael Juma <is...@juma.me.uk>
>> >> > wrote:
>> >> >
>> >> >> Which changes break compatibility in the 0.10.1 branch? It would be
>> >> >> good
>> >> >> to
>> >> >> fix before the release goes out.
>> >> >>
>> >> >> Ismael
>> >> >>
>> >> >> On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
>> >> >>
>> >> >> > Some of the changes in the 0.10.1 branch already are not bug
>> >> >> > fixes.
>> >> Some
>> >> >> > break compatibility.
>> >> >> >
>> >> >> > Having said that, at this level we should maintain a stable API
>> >> >> > and
>> >> >> leave
>> >> >> > any changes for real version bumps. This should be only a bugfix
>> >> >> release.
>> >> >> >
>> >> >> > Nacho
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <is...@juma.me.uk>
>> >> wrote:
>> >> >> >
>> >> >> > > I disagree, but let's discuss it another time and in a separate
>> >> >> thread.
>> >> >> > :)
>> >> >> > >
>> >> >> > > Ismael
>> >> >> > >
>> >> >> > > On Tue, Nov 29, 2016 at 4:30 PM, radai
>> >> >> > > <ra...@gmail.com>
>> >> >> > wrote:
>> >> >> > >
>> >> >> > > > designing kafka code for stable extensibility is a worthy and
>> >> noble
>> >> >> > > cause.
>> >> >> > > > however, seeing as there are no such derivatives out in the
>> >> >> > > > wild
>> >> >> yet i
>> >> >> > > > think investing the effort right now is a bit premature from
>> >> kafka's
>> >> >> > pov.
>> >> >> > > > I think its enough simply not to purposefully prevent such
>> >> >> extensions.
>> >> >> > > >
>> >> >> > > > On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma
>> >> >> > > > <is...@juma.me.uk>
>> >> >> > wrote:
>> >> >> > > >
>> >> >> > > > > On Sat, Nov 26, 2016 at 11:08 PM, radai <
>> >> >> radai.rosenblatt@gmail.com>
>> >> >> > > > > wrote:
>> >> >> > > > >
>> >> >> > > > > > "compatibility guarantees that are expected by people who
>> >> >> subclass
>> >> >> > > > these
>> >> >> > > > > > classes"
>> >> >> > > > > >
>> >> >> > > > > > sorry if this is not the best thread for this discussion,
>> >> >> > > > > > but
>> >> I
>> >> >> > just
>> >> >> > > > > wanted
>> >> >> > > > > > to pop in and say that since any subclassing of these will
>> >> >> > obviously
>> >> >> > > > not
>> >> >> > > > > be
>> >> >> > > > > > done within the kafka codebase - what guarantees are
>> >> >> > > > > > needed?
>> >> >> > > > > >
>> >> >> > > > >
>> >> >> > > > > I elaborated a little in my other message in this thread. A
>> >> simple
>> >> >> > and
>> >> >> > > > > somewhat contrived example: `ConsumerRecord.toString` calls
>> >> >> > > > > the
>> >> >> > `topic`
>> >> >> > > > > method. Someone overrides the `topic` method and it all
>> >> >> > > > > works as
>> >> >> > > > expected.
>> >> >> > > > > In a subsequent release, we change `toString` to use the
>> >> >> > > > > field
>> >> >> > directly
>> >> >> > > > > (like it's done for other fields like `key` and `value`) and
>> >> >> > > > > it
>> >> >> will
>> >> >> > > > break
>> >> >> > > > > `toString` for this user. One may wonder: why would one
>> >> override a
>> >> >> > > method
>> >> >> > > > > like `topic`? That is a good question, but part of the
>> >> >> > > > > exercise
>> >> is
>> >> >> > > > deciding
>> >> >> > > > > how we approach these issues. We could make the methods
>> >> >> > > > > final
>> >> and
>> >> >> > > > eliminate
>> >> >> > > > > the possibility, we could document it so that users can
>> >> >> > > > > choose
>> >> to
>> >> >> do
>> >> >> > > > weird
>> >> >> > > > > things if they want, etc.
>> >> >> > > > >
>> >> >> > > > > Another thing that is usually good to think about is the
>> >> >> expectation
>> >> >> > > for
>> >> >> > > > > `equals` and `hashCode`. What if subclasses implement them
>> >> >> > > > > to
>> >> have
>> >> >> > > value
>> >> >> > > > > semantics instead of identity semantics. Is that OK or would
>> >> >> > > > > it
>> >> >> break
>> >> >> > > > > things?
>> >> >> > > > >
>> >> >> > > > > Designing for implementation inheritance is generally
>> >> >> > > > > complex
>> >> >> > although
>> >> >> > > > for
>> >> >> > > > > simple "record" like classes, it can be easier by following
>> >> >> > > > > a
>> >> few
>> >> >> > > > > guidelines.
>> >> >> > > > >
>> >> >> > > > > Ismael
>> >> >> > > > >
>> >> >> > > >
>> >> >> > >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Nacho - Ignacio Solis - isolis@igso.net
>> >> >> >
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Nacho - Ignacio Solis - isolis@igso.net
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Nacho - Ignacio Solis - isolis@igso.net
>> >>
>>
>>
>>
>> --
>> 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: [DISCUSS] 0.10.1.1 Plan
Posted by Guozhang Wang <wa...@gmail.com>.
Status Update:
All tasks marked for 0.10.1.1 as been resolved, will start the release
process right away.
Guozhang
On Fri, Dec 2, 2016 at 1:01 PM, Guozhang Wang <wa...@gmail.com> wrote:
> @Sean,
>
> There have been some discussions about KAFKA-4250, from Ismael. The main
> concern is on backward compatibility between 0.10.1.0 and the coming
> 0.10.1.1.
>
>
> Status Update:
>
> We are having three tasks left for 0.10.1.1, all of which have a PR under
> review and close to be merged. After those three I will start the release
> process and start a separate thread on the RC voting.
>
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%
> 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> 20DESC%2C%20key%20DESC
>
>
> Guozhang
>
>
> On Thu, Dec 1, 2016 at 4:40 PM, Sean McCauliff <se...@gmail.com>
> wrote:
>
>> Well I would like KAFKA-4250 (make ProducerRecord and ConsumerRecord
>> extensible) in the 0.10.1 branch if is not a big deal. They are just
>> dumb structs. But they are final so no extensibility is possible.
>>
>> Sean
>>
>> On Tue, Nov 29, 2016 at 5:32 PM, Ignacio Solis <is...@igso.net> wrote:
>> > I don't think anybody from LinkedIn asked for features on this
>> release. We
>> > just jumped in at the discussion of including a patch which was not a
>> bug
>> > fix and whether it mattered.
>> >
>> > Having said that, the internal release we're working on came off the
>> 0.10.1
>> > branch with a few internal hotfix patches and a few cherry picked
>> fixes...
>> > Including the final keyword removal patch.
>> >
>> > Nacho
>> >
>> > On Tue, Nov 29, 2016, 5:15 PM Gwen Shapira <gw...@confluent.io> wrote:
>> >
>> >> btw. is LinkedIn no longer running from trunk? I'm not used to
>> >> LinkedIn employees requesting specific patches to be included in a
>> >> bugfix release.
>> >>
>> >> Any discussion on the content of any release is obviously welcome, I'm
>> >> just wondering if there was a change in policy.
>> >>
>> >> On Tue, Nov 29, 2016 at 2:17 PM, Ismael Juma <is...@juma.me.uk>
>> wrote:
>> >> > OK, so it seems like there are no changes that break compatibility
>> in the
>> >> > 0.10.1 branch since we offer no compatibility guarantees for logging
>> >> > output. That's good. :)
>> >> >
>> >> > About the removal of final, it happened in trunk and it doesn't seem
>> like
>> >> > anyone is still asking for it to be included in the 0.10.1 branch so
>> it
>> >> is
>> >> > indeed not important for this bug fix release (I thought we had
>> >> established
>> >> > that quite a while ago).
>> >> >
>> >> > Ismael
>> >> >
>> >> > On Tue, Nov 29, 2016 at 9:35 PM, Ignacio Solis <is...@igso.net>
>> wrote:
>> >> >
>> >> >> Sorry, that was a hasty reply. There are also various logging
>> things
>> >> that
>> >> >> change format. This could break parsers.
>> >> >>
>> >> >> None of them are important, my only argument is that the final
>> keyword
>> >> >> removal is not important either.
>> >> >>
>> >> >> Nacho
>> >> >>
>> >> >>
>> >> >> On Tue, Nov 29, 2016 at 1:25 PM, Ignacio Solis <is...@igso.net>
>> wrote:
>> >> >>
>> >> >> > https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=
>> >> >> > 10cfc1628df024f7596d3af5c168fa90f59035ca
>> >> >> >
>> >> >> > On Tue, Nov 29, 2016 at 1:24 PM, Ismael Juma <is...@juma.me.uk>
>> >> wrote:
>> >> >> >
>> >> >> >> Which changes break compatibility in the 0.10.1 branch? It would
>> be
>> >> good
>> >> >> >> to
>> >> >> >> fix before the release goes out.
>> >> >> >>
>> >> >> >> Ismael
>> >> >> >>
>> >> >> >> On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
>> >> >> >>
>> >> >> >> > Some of the changes in the 0.10.1 branch already are not bug
>> fixes.
>> >> >> Some
>> >> >> >> > break compatibility.
>> >> >> >> >
>> >> >> >> > Having said that, at this level we should maintain a stable
>> API and
>> >> >> >> leave
>> >> >> >> > any changes for real version bumps. This should be only a
>> bugfix
>> >> >> >> release.
>> >> >> >> >
>> >> >> >> > Nacho
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <
>> ismael@juma.me.uk>
>> >> >> wrote:
>> >> >> >> >
>> >> >> >> > > I disagree, but let's discuss it another time and in a
>> separate
>> >> >> >> thread.
>> >> >> >> > :)
>> >> >> >> > >
>> >> >> >> > > Ismael
>> >> >> >> > >
>> >> >> >> > > On Tue, Nov 29, 2016 at 4:30 PM, radai <
>> >> radai.rosenblatt@gmail.com>
>> >> >> >> > wrote:
>> >> >> >> > >
>> >> >> >> > > > designing kafka code for stable extensibility is a worthy
>> and
>> >> >> noble
>> >> >> >> > > cause.
>> >> >> >> > > > however, seeing as there are no such derivatives out in the
>> >> wild
>> >> >> >> yet i
>> >> >> >> > > > think investing the effort right now is a bit premature
>> from
>> >> >> kafka's
>> >> >> >> > pov.
>> >> >> >> > > > I think its enough simply not to purposefully prevent such
>> >> >> >> extensions.
>> >> >> >> > > >
>> >> >> >> > > > On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <
>> >> ismael@juma.me.uk>
>> >> >> >> > wrote:
>> >> >> >> > > >
>> >> >> >> > > > > On Sat, Nov 26, 2016 at 11:08 PM, radai <
>> >> >> >> radai.rosenblatt@gmail.com>
>> >> >> >> > > > > wrote:
>> >> >> >> > > > >
>> >> >> >> > > > > > "compatibility guarantees that are expected by people
>> who
>> >> >> >> subclass
>> >> >> >> > > > these
>> >> >> >> > > > > > classes"
>> >> >> >> > > > > >
>> >> >> >> > > > > > sorry if this is not the best thread for this
>> discussion,
>> >> but
>> >> >> I
>> >> >> >> > just
>> >> >> >> > > > > wanted
>> >> >> >> > > > > > to pop in and say that since any subclassing of these
>> will
>> >> >> >> > obviously
>> >> >> >> > > > not
>> >> >> >> > > > > be
>> >> >> >> > > > > > done within the kafka codebase - what guarantees are
>> >> needed?
>> >> >> >> > > > > >
>> >> >> >> > > > >
>> >> >> >> > > > > I elaborated a little in my other message in this
>> thread. A
>> >> >> simple
>> >> >> >> > and
>> >> >> >> > > > > somewhat contrived example: `ConsumerRecord.toString`
>> calls
>> >> the
>> >> >> >> > `topic`
>> >> >> >> > > > > method. Someone overrides the `topic` method and it all
>> >> works as
>> >> >> >> > > > expected.
>> >> >> >> > > > > In a subsequent release, we change `toString` to use the
>> >> field
>> >> >> >> > directly
>> >> >> >> > > > > (like it's done for other fields like `key` and `value`)
>> and
>> >> it
>> >> >> >> will
>> >> >> >> > > > break
>> >> >> >> > > > > `toString` for this user. One may wonder: why would one
>> >> >> override a
>> >> >> >> > > method
>> >> >> >> > > > > like `topic`? That is a good question, but part of the
>> >> exercise
>> >> >> is
>> >> >> >> > > > deciding
>> >> >> >> > > > > how we approach these issues. We could make the methods
>> final
>> >> >> and
>> >> >> >> > > > eliminate
>> >> >> >> > > > > the possibility, we could document it so that users can
>> >> choose
>> >> >> to
>> >> >> >> do
>> >> >> >> > > > weird
>> >> >> >> > > > > things if they want, etc.
>> >> >> >> > > > >
>> >> >> >> > > > > Another thing that is usually good to think about is the
>> >> >> >> expectation
>> >> >> >> > > for
>> >> >> >> > > > > `equals` and `hashCode`. What if subclasses implement
>> them to
>> >> >> have
>> >> >> >> > > value
>> >> >> >> > > > > semantics instead of identity semantics. Is that OK or
>> would
>> >> it
>> >> >> >> break
>> >> >> >> > > > > things?
>> >> >> >> > > > >
>> >> >> >> > > > > Designing for implementation inheritance is generally
>> complex
>> >> >> >> > although
>> >> >> >> > > > for
>> >> >> >> > > > > simple "record" like classes, it can be easier by
>> following a
>> >> >> few
>> >> >> >> > > > > guidelines.
>> >> >> >> > > > >
>> >> >> >> > > > > Ismael
>> >> >> >> > > > >
>> >> >> >> > > >
>> >> >> >> > >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > --
>> >> >> >> > Nacho - Ignacio Solis - isolis@igso.net
>> >> >> >> >
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Nacho - Ignacio Solis - isolis@igso.net
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Nacho - Ignacio Solis - isolis@igso.net
>> >> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Gwen Shapira
>> >> Product Manager | Confluent
>> >> 650.450.2760 | @gwenshap
>> >> Follow us: Twitter | blog
>> >>
>>
>
>
>
> --
> -- Guozhang
>
--
-- Guozhang
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Guozhang Wang <wa...@gmail.com>.
@Sean,
There have been some discussions about KAFKA-4250, from Ismael. The main
concern is on backward compatibility between 0.10.1.0 and the coming
0.10.1.1.
Status Update:
We are having three tasks left for 0.10.1.1, all of which have a PR under
review and close to be merged. After those three I will start the release
process and start a separate thread on the RC voting.
https://issues.apache.org/jira/issues/?jql=project%20%3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC
Guozhang
On Thu, Dec 1, 2016 at 4:40 PM, Sean McCauliff <se...@gmail.com>
wrote:
> Well I would like KAFKA-4250 (make ProducerRecord and ConsumerRecord
> extensible) in the 0.10.1 branch if is not a big deal. They are just
> dumb structs. But they are final so no extensibility is possible.
>
> Sean
>
> On Tue, Nov 29, 2016 at 5:32 PM, Ignacio Solis <is...@igso.net> wrote:
> > I don't think anybody from LinkedIn asked for features on this release.
> We
> > just jumped in at the discussion of including a patch which was not a bug
> > fix and whether it mattered.
> >
> > Having said that, the internal release we're working on came off the
> 0.10.1
> > branch with a few internal hotfix patches and a few cherry picked
> fixes...
> > Including the final keyword removal patch.
> >
> > Nacho
> >
> > On Tue, Nov 29, 2016, 5:15 PM Gwen Shapira <gw...@confluent.io> wrote:
> >
> >> btw. is LinkedIn no longer running from trunk? I'm not used to
> >> LinkedIn employees requesting specific patches to be included in a
> >> bugfix release.
> >>
> >> Any discussion on the content of any release is obviously welcome, I'm
> >> just wondering if there was a change in policy.
> >>
> >> On Tue, Nov 29, 2016 at 2:17 PM, Ismael Juma <is...@juma.me.uk> wrote:
> >> > OK, so it seems like there are no changes that break compatibility in
> the
> >> > 0.10.1 branch since we offer no compatibility guarantees for logging
> >> > output. That's good. :)
> >> >
> >> > About the removal of final, it happened in trunk and it doesn't seem
> like
> >> > anyone is still asking for it to be included in the 0.10.1 branch so
> it
> >> is
> >> > indeed not important for this bug fix release (I thought we had
> >> established
> >> > that quite a while ago).
> >> >
> >> > Ismael
> >> >
> >> > On Tue, Nov 29, 2016 at 9:35 PM, Ignacio Solis <is...@igso.net>
> wrote:
> >> >
> >> >> Sorry, that was a hasty reply. There are also various logging things
> >> that
> >> >> change format. This could break parsers.
> >> >>
> >> >> None of them are important, my only argument is that the final
> keyword
> >> >> removal is not important either.
> >> >>
> >> >> Nacho
> >> >>
> >> >>
> >> >> On Tue, Nov 29, 2016 at 1:25 PM, Ignacio Solis <is...@igso.net>
> wrote:
> >> >>
> >> >> > https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=
> >> >> > 10cfc1628df024f7596d3af5c168fa90f59035ca
> >> >> >
> >> >> > On Tue, Nov 29, 2016 at 1:24 PM, Ismael Juma <is...@juma.me.uk>
> >> wrote:
> >> >> >
> >> >> >> Which changes break compatibility in the 0.10.1 branch? It would
> be
> >> good
> >> >> >> to
> >> >> >> fix before the release goes out.
> >> >> >>
> >> >> >> Ismael
> >> >> >>
> >> >> >> On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
> >> >> >>
> >> >> >> > Some of the changes in the 0.10.1 branch already are not bug
> fixes.
> >> >> Some
> >> >> >> > break compatibility.
> >> >> >> >
> >> >> >> > Having said that, at this level we should maintain a stable API
> and
> >> >> >> leave
> >> >> >> > any changes for real version bumps. This should be only a
> bugfix
> >> >> >> release.
> >> >> >> >
> >> >> >> > Nacho
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <ismael@juma.me.uk
> >
> >> >> wrote:
> >> >> >> >
> >> >> >> > > I disagree, but let's discuss it another time and in a
> separate
> >> >> >> thread.
> >> >> >> > :)
> >> >> >> > >
> >> >> >> > > Ismael
> >> >> >> > >
> >> >> >> > > On Tue, Nov 29, 2016 at 4:30 PM, radai <
> >> radai.rosenblatt@gmail.com>
> >> >> >> > wrote:
> >> >> >> > >
> >> >> >> > > > designing kafka code for stable extensibility is a worthy
> and
> >> >> noble
> >> >> >> > > cause.
> >> >> >> > > > however, seeing as there are no such derivatives out in the
> >> wild
> >> >> >> yet i
> >> >> >> > > > think investing the effort right now is a bit premature from
> >> >> kafka's
> >> >> >> > pov.
> >> >> >> > > > I think its enough simply not to purposefully prevent such
> >> >> >> extensions.
> >> >> >> > > >
> >> >> >> > > > On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <
> >> ismael@juma.me.uk>
> >> >> >> > wrote:
> >> >> >> > > >
> >> >> >> > > > > On Sat, Nov 26, 2016 at 11:08 PM, radai <
> >> >> >> radai.rosenblatt@gmail.com>
> >> >> >> > > > > wrote:
> >> >> >> > > > >
> >> >> >> > > > > > "compatibility guarantees that are expected by people
> who
> >> >> >> subclass
> >> >> >> > > > these
> >> >> >> > > > > > classes"
> >> >> >> > > > > >
> >> >> >> > > > > > sorry if this is not the best thread for this
> discussion,
> >> but
> >> >> I
> >> >> >> > just
> >> >> >> > > > > wanted
> >> >> >> > > > > > to pop in and say that since any subclassing of these
> will
> >> >> >> > obviously
> >> >> >> > > > not
> >> >> >> > > > > be
> >> >> >> > > > > > done within the kafka codebase - what guarantees are
> >> needed?
> >> >> >> > > > > >
> >> >> >> > > > >
> >> >> >> > > > > I elaborated a little in my other message in this thread.
> A
> >> >> simple
> >> >> >> > and
> >> >> >> > > > > somewhat contrived example: `ConsumerRecord.toString`
> calls
> >> the
> >> >> >> > `topic`
> >> >> >> > > > > method. Someone overrides the `topic` method and it all
> >> works as
> >> >> >> > > > expected.
> >> >> >> > > > > In a subsequent release, we change `toString` to use the
> >> field
> >> >> >> > directly
> >> >> >> > > > > (like it's done for other fields like `key` and `value`)
> and
> >> it
> >> >> >> will
> >> >> >> > > > break
> >> >> >> > > > > `toString` for this user. One may wonder: why would one
> >> >> override a
> >> >> >> > > method
> >> >> >> > > > > like `topic`? That is a good question, but part of the
> >> exercise
> >> >> is
> >> >> >> > > > deciding
> >> >> >> > > > > how we approach these issues. We could make the methods
> final
> >> >> and
> >> >> >> > > > eliminate
> >> >> >> > > > > the possibility, we could document it so that users can
> >> choose
> >> >> to
> >> >> >> do
> >> >> >> > > > weird
> >> >> >> > > > > things if they want, etc.
> >> >> >> > > > >
> >> >> >> > > > > Another thing that is usually good to think about is the
> >> >> >> expectation
> >> >> >> > > for
> >> >> >> > > > > `equals` and `hashCode`. What if subclasses implement
> them to
> >> >> have
> >> >> >> > > value
> >> >> >> > > > > semantics instead of identity semantics. Is that OK or
> would
> >> it
> >> >> >> break
> >> >> >> > > > > things?
> >> >> >> > > > >
> >> >> >> > > > > Designing for implementation inheritance is generally
> complex
> >> >> >> > although
> >> >> >> > > > for
> >> >> >> > > > > simple "record" like classes, it can be easier by
> following a
> >> >> few
> >> >> >> > > > > guidelines.
> >> >> >> > > > >
> >> >> >> > > > > Ismael
> >> >> >> > > > >
> >> >> >> > > >
> >> >> >> > >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > Nacho - Ignacio Solis - isolis@igso.net
> >> >> >> >
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Nacho - Ignacio Solis - isolis@igso.net
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Nacho - Ignacio Solis - isolis@igso.net
> >> >>
> >>
> >>
> >>
> >> --
> >> Gwen Shapira
> >> Product Manager | Confluent
> >> 650.450.2760 | @gwenshap
> >> Follow us: Twitter | blog
> >>
>
--
-- Guozhang
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Sean McCauliff <se...@gmail.com>.
Well I would like KAFKA-4250 (make ProducerRecord and ConsumerRecord
extensible) in the 0.10.1 branch if is not a big deal. They are just
dumb structs. But they are final so no extensibility is possible.
Sean
On Tue, Nov 29, 2016 at 5:32 PM, Ignacio Solis <is...@igso.net> wrote:
> I don't think anybody from LinkedIn asked for features on this release. We
> just jumped in at the discussion of including a patch which was not a bug
> fix and whether it mattered.
>
> Having said that, the internal release we're working on came off the 0.10.1
> branch with a few internal hotfix patches and a few cherry picked fixes...
> Including the final keyword removal patch.
>
> Nacho
>
> On Tue, Nov 29, 2016, 5:15 PM Gwen Shapira <gw...@confluent.io> wrote:
>
>> btw. is LinkedIn no longer running from trunk? I'm not used to
>> LinkedIn employees requesting specific patches to be included in a
>> bugfix release.
>>
>> Any discussion on the content of any release is obviously welcome, I'm
>> just wondering if there was a change in policy.
>>
>> On Tue, Nov 29, 2016 at 2:17 PM, Ismael Juma <is...@juma.me.uk> wrote:
>> > OK, so it seems like there are no changes that break compatibility in the
>> > 0.10.1 branch since we offer no compatibility guarantees for logging
>> > output. That's good. :)
>> >
>> > About the removal of final, it happened in trunk and it doesn't seem like
>> > anyone is still asking for it to be included in the 0.10.1 branch so it
>> is
>> > indeed not important for this bug fix release (I thought we had
>> established
>> > that quite a while ago).
>> >
>> > Ismael
>> >
>> > On Tue, Nov 29, 2016 at 9:35 PM, Ignacio Solis <is...@igso.net> wrote:
>> >
>> >> Sorry, that was a hasty reply. There are also various logging things
>> that
>> >> change format. This could break parsers.
>> >>
>> >> None of them are important, my only argument is that the final keyword
>> >> removal is not important either.
>> >>
>> >> Nacho
>> >>
>> >>
>> >> On Tue, Nov 29, 2016 at 1:25 PM, Ignacio Solis <is...@igso.net> wrote:
>> >>
>> >> > https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=
>> >> > 10cfc1628df024f7596d3af5c168fa90f59035ca
>> >> >
>> >> > On Tue, Nov 29, 2016 at 1:24 PM, Ismael Juma <is...@juma.me.uk>
>> wrote:
>> >> >
>> >> >> Which changes break compatibility in the 0.10.1 branch? It would be
>> good
>> >> >> to
>> >> >> fix before the release goes out.
>> >> >>
>> >> >> Ismael
>> >> >>
>> >> >> On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
>> >> >>
>> >> >> > Some of the changes in the 0.10.1 branch already are not bug fixes.
>> >> Some
>> >> >> > break compatibility.
>> >> >> >
>> >> >> > Having said that, at this level we should maintain a stable API and
>> >> >> leave
>> >> >> > any changes for real version bumps. This should be only a bugfix
>> >> >> release.
>> >> >> >
>> >> >> > Nacho
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <is...@juma.me.uk>
>> >> wrote:
>> >> >> >
>> >> >> > > I disagree, but let's discuss it another time and in a separate
>> >> >> thread.
>> >> >> > :)
>> >> >> > >
>> >> >> > > Ismael
>> >> >> > >
>> >> >> > > On Tue, Nov 29, 2016 at 4:30 PM, radai <
>> radai.rosenblatt@gmail.com>
>> >> >> > wrote:
>> >> >> > >
>> >> >> > > > designing kafka code for stable extensibility is a worthy and
>> >> noble
>> >> >> > > cause.
>> >> >> > > > however, seeing as there are no such derivatives out in the
>> wild
>> >> >> yet i
>> >> >> > > > think investing the effort right now is a bit premature from
>> >> kafka's
>> >> >> > pov.
>> >> >> > > > I think its enough simply not to purposefully prevent such
>> >> >> extensions.
>> >> >> > > >
>> >> >> > > > On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <
>> ismael@juma.me.uk>
>> >> >> > wrote:
>> >> >> > > >
>> >> >> > > > > On Sat, Nov 26, 2016 at 11:08 PM, radai <
>> >> >> radai.rosenblatt@gmail.com>
>> >> >> > > > > wrote:
>> >> >> > > > >
>> >> >> > > > > > "compatibility guarantees that are expected by people who
>> >> >> subclass
>> >> >> > > > these
>> >> >> > > > > > classes"
>> >> >> > > > > >
>> >> >> > > > > > sorry if this is not the best thread for this discussion,
>> but
>> >> I
>> >> >> > just
>> >> >> > > > > wanted
>> >> >> > > > > > to pop in and say that since any subclassing of these will
>> >> >> > obviously
>> >> >> > > > not
>> >> >> > > > > be
>> >> >> > > > > > done within the kafka codebase - what guarantees are
>> needed?
>> >> >> > > > > >
>> >> >> > > > >
>> >> >> > > > > I elaborated a little in my other message in this thread. A
>> >> simple
>> >> >> > and
>> >> >> > > > > somewhat contrived example: `ConsumerRecord.toString` calls
>> the
>> >> >> > `topic`
>> >> >> > > > > method. Someone overrides the `topic` method and it all
>> works as
>> >> >> > > > expected.
>> >> >> > > > > In a subsequent release, we change `toString` to use the
>> field
>> >> >> > directly
>> >> >> > > > > (like it's done for other fields like `key` and `value`) and
>> it
>> >> >> will
>> >> >> > > > break
>> >> >> > > > > `toString` for this user. One may wonder: why would one
>> >> override a
>> >> >> > > method
>> >> >> > > > > like `topic`? That is a good question, but part of the
>> exercise
>> >> is
>> >> >> > > > deciding
>> >> >> > > > > how we approach these issues. We could make the methods final
>> >> and
>> >> >> > > > eliminate
>> >> >> > > > > the possibility, we could document it so that users can
>> choose
>> >> to
>> >> >> do
>> >> >> > > > weird
>> >> >> > > > > things if they want, etc.
>> >> >> > > > >
>> >> >> > > > > Another thing that is usually good to think about is the
>> >> >> expectation
>> >> >> > > for
>> >> >> > > > > `equals` and `hashCode`. What if subclasses implement them to
>> >> have
>> >> >> > > value
>> >> >> > > > > semantics instead of identity semantics. Is that OK or would
>> it
>> >> >> break
>> >> >> > > > > things?
>> >> >> > > > >
>> >> >> > > > > Designing for implementation inheritance is generally complex
>> >> >> > although
>> >> >> > > > for
>> >> >> > > > > simple "record" like classes, it can be easier by following a
>> >> few
>> >> >> > > > > guidelines.
>> >> >> > > > >
>> >> >> > > > > Ismael
>> >> >> > > > >
>> >> >> > > >
>> >> >> > >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Nacho - Ignacio Solis - isolis@igso.net
>> >> >> >
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Nacho - Ignacio Solis - isolis@igso.net
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Nacho - Ignacio Solis - isolis@igso.net
>> >>
>>
>>
>>
>> --
>> Gwen Shapira
>> Product Manager | Confluent
>> 650.450.2760 | @gwenshap
>> Follow us: Twitter | blog
>>
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Ignacio Solis <is...@igso.net>.
I don't think anybody from LinkedIn asked for features on this release. We
just jumped in at the discussion of including a patch which was not a bug
fix and whether it mattered.
Having said that, the internal release we're working on came off the 0.10.1
branch with a few internal hotfix patches and a few cherry picked fixes...
Including the final keyword removal patch.
Nacho
On Tue, Nov 29, 2016, 5:15 PM Gwen Shapira <gw...@confluent.io> wrote:
> btw. is LinkedIn no longer running from trunk? I'm not used to
> LinkedIn employees requesting specific patches to be included in a
> bugfix release.
>
> Any discussion on the content of any release is obviously welcome, I'm
> just wondering if there was a change in policy.
>
> On Tue, Nov 29, 2016 at 2:17 PM, Ismael Juma <is...@juma.me.uk> wrote:
> > OK, so it seems like there are no changes that break compatibility in the
> > 0.10.1 branch since we offer no compatibility guarantees for logging
> > output. That's good. :)
> >
> > About the removal of final, it happened in trunk and it doesn't seem like
> > anyone is still asking for it to be included in the 0.10.1 branch so it
> is
> > indeed not important for this bug fix release (I thought we had
> established
> > that quite a while ago).
> >
> > Ismael
> >
> > On Tue, Nov 29, 2016 at 9:35 PM, Ignacio Solis <is...@igso.net> wrote:
> >
> >> Sorry, that was a hasty reply. There are also various logging things
> that
> >> change format. This could break parsers.
> >>
> >> None of them are important, my only argument is that the final keyword
> >> removal is not important either.
> >>
> >> Nacho
> >>
> >>
> >> On Tue, Nov 29, 2016 at 1:25 PM, Ignacio Solis <is...@igso.net> wrote:
> >>
> >> > https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=
> >> > 10cfc1628df024f7596d3af5c168fa90f59035ca
> >> >
> >> > On Tue, Nov 29, 2016 at 1:24 PM, Ismael Juma <is...@juma.me.uk>
> wrote:
> >> >
> >> >> Which changes break compatibility in the 0.10.1 branch? It would be
> good
> >> >> to
> >> >> fix before the release goes out.
> >> >>
> >> >> Ismael
> >> >>
> >> >> On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
> >> >>
> >> >> > Some of the changes in the 0.10.1 branch already are not bug fixes.
> >> Some
> >> >> > break compatibility.
> >> >> >
> >> >> > Having said that, at this level we should maintain a stable API and
> >> >> leave
> >> >> > any changes for real version bumps. This should be only a bugfix
> >> >> release.
> >> >> >
> >> >> > Nacho
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <is...@juma.me.uk>
> >> wrote:
> >> >> >
> >> >> > > I disagree, but let's discuss it another time and in a separate
> >> >> thread.
> >> >> > :)
> >> >> > >
> >> >> > > Ismael
> >> >> > >
> >> >> > > On Tue, Nov 29, 2016 at 4:30 PM, radai <
> radai.rosenblatt@gmail.com>
> >> >> > wrote:
> >> >> > >
> >> >> > > > designing kafka code for stable extensibility is a worthy and
> >> noble
> >> >> > > cause.
> >> >> > > > however, seeing as there are no such derivatives out in the
> wild
> >> >> yet i
> >> >> > > > think investing the effort right now is a bit premature from
> >> kafka's
> >> >> > pov.
> >> >> > > > I think its enough simply not to purposefully prevent such
> >> >> extensions.
> >> >> > > >
> >> >> > > > On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <
> ismael@juma.me.uk>
> >> >> > wrote:
> >> >> > > >
> >> >> > > > > On Sat, Nov 26, 2016 at 11:08 PM, radai <
> >> >> radai.rosenblatt@gmail.com>
> >> >> > > > > wrote:
> >> >> > > > >
> >> >> > > > > > "compatibility guarantees that are expected by people who
> >> >> subclass
> >> >> > > > these
> >> >> > > > > > classes"
> >> >> > > > > >
> >> >> > > > > > sorry if this is not the best thread for this discussion,
> but
> >> I
> >> >> > just
> >> >> > > > > wanted
> >> >> > > > > > to pop in and say that since any subclassing of these will
> >> >> > obviously
> >> >> > > > not
> >> >> > > > > be
> >> >> > > > > > done within the kafka codebase - what guarantees are
> needed?
> >> >> > > > > >
> >> >> > > > >
> >> >> > > > > I elaborated a little in my other message in this thread. A
> >> simple
> >> >> > and
> >> >> > > > > somewhat contrived example: `ConsumerRecord.toString` calls
> the
> >> >> > `topic`
> >> >> > > > > method. Someone overrides the `topic` method and it all
> works as
> >> >> > > > expected.
> >> >> > > > > In a subsequent release, we change `toString` to use the
> field
> >> >> > directly
> >> >> > > > > (like it's done for other fields like `key` and `value`) and
> it
> >> >> will
> >> >> > > > break
> >> >> > > > > `toString` for this user. One may wonder: why would one
> >> override a
> >> >> > > method
> >> >> > > > > like `topic`? That is a good question, but part of the
> exercise
> >> is
> >> >> > > > deciding
> >> >> > > > > how we approach these issues. We could make the methods final
> >> and
> >> >> > > > eliminate
> >> >> > > > > the possibility, we could document it so that users can
> choose
> >> to
> >> >> do
> >> >> > > > weird
> >> >> > > > > things if they want, etc.
> >> >> > > > >
> >> >> > > > > Another thing that is usually good to think about is the
> >> >> expectation
> >> >> > > for
> >> >> > > > > `equals` and `hashCode`. What if subclasses implement them to
> >> have
> >> >> > > value
> >> >> > > > > semantics instead of identity semantics. Is that OK or would
> it
> >> >> break
> >> >> > > > > things?
> >> >> > > > >
> >> >> > > > > Designing for implementation inheritance is generally complex
> >> >> > although
> >> >> > > > for
> >> >> > > > > simple "record" like classes, it can be easier by following a
> >> few
> >> >> > > > > guidelines.
> >> >> > > > >
> >> >> > > > > Ismael
> >> >> > > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Nacho - Ignacio Solis - isolis@igso.net
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Nacho - Ignacio Solis - isolis@igso.net
> >> >
> >>
> >>
> >>
> >> --
> >> Nacho - Ignacio Solis - isolis@igso.net
> >>
>
>
>
> --
> Gwen Shapira
> Product Manager | Confluent
> 650.450.2760 | @gwenshap
> Follow us: Twitter | blog
>
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Gwen Shapira <gw...@confluent.io>.
btw. is LinkedIn no longer running from trunk? I'm not used to
LinkedIn employees requesting specific patches to be included in a
bugfix release.
Any discussion on the content of any release is obviously welcome, I'm
just wondering if there was a change in policy.
On Tue, Nov 29, 2016 at 2:17 PM, Ismael Juma <is...@juma.me.uk> wrote:
> OK, so it seems like there are no changes that break compatibility in the
> 0.10.1 branch since we offer no compatibility guarantees for logging
> output. That's good. :)
>
> About the removal of final, it happened in trunk and it doesn't seem like
> anyone is still asking for it to be included in the 0.10.1 branch so it is
> indeed not important for this bug fix release (I thought we had established
> that quite a while ago).
>
> Ismael
>
> On Tue, Nov 29, 2016 at 9:35 PM, Ignacio Solis <is...@igso.net> wrote:
>
>> Sorry, that was a hasty reply. There are also various logging things that
>> change format. This could break parsers.
>>
>> None of them are important, my only argument is that the final keyword
>> removal is not important either.
>>
>> Nacho
>>
>>
>> On Tue, Nov 29, 2016 at 1:25 PM, Ignacio Solis <is...@igso.net> wrote:
>>
>> > https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=
>> > 10cfc1628df024f7596d3af5c168fa90f59035ca
>> >
>> > On Tue, Nov 29, 2016 at 1:24 PM, Ismael Juma <is...@juma.me.uk> wrote:
>> >
>> >> Which changes break compatibility in the 0.10.1 branch? It would be good
>> >> to
>> >> fix before the release goes out.
>> >>
>> >> Ismael
>> >>
>> >> On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
>> >>
>> >> > Some of the changes in the 0.10.1 branch already are not bug fixes.
>> Some
>> >> > break compatibility.
>> >> >
>> >> > Having said that, at this level we should maintain a stable API and
>> >> leave
>> >> > any changes for real version bumps. This should be only a bugfix
>> >> release.
>> >> >
>> >> > Nacho
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <is...@juma.me.uk>
>> wrote:
>> >> >
>> >> > > I disagree, but let's discuss it another time and in a separate
>> >> thread.
>> >> > :)
>> >> > >
>> >> > > Ismael
>> >> > >
>> >> > > On Tue, Nov 29, 2016 at 4:30 PM, radai <ra...@gmail.com>
>> >> > wrote:
>> >> > >
>> >> > > > designing kafka code for stable extensibility is a worthy and
>> noble
>> >> > > cause.
>> >> > > > however, seeing as there are no such derivatives out in the wild
>> >> yet i
>> >> > > > think investing the effort right now is a bit premature from
>> kafka's
>> >> > pov.
>> >> > > > I think its enough simply not to purposefully prevent such
>> >> extensions.
>> >> > > >
>> >> > > > On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <is...@juma.me.uk>
>> >> > wrote:
>> >> > > >
>> >> > > > > On Sat, Nov 26, 2016 at 11:08 PM, radai <
>> >> radai.rosenblatt@gmail.com>
>> >> > > > > wrote:
>> >> > > > >
>> >> > > > > > "compatibility guarantees that are expected by people who
>> >> subclass
>> >> > > > these
>> >> > > > > > classes"
>> >> > > > > >
>> >> > > > > > sorry if this is not the best thread for this discussion, but
>> I
>> >> > just
>> >> > > > > wanted
>> >> > > > > > to pop in and say that since any subclassing of these will
>> >> > obviously
>> >> > > > not
>> >> > > > > be
>> >> > > > > > done within the kafka codebase - what guarantees are needed?
>> >> > > > > >
>> >> > > > >
>> >> > > > > I elaborated a little in my other message in this thread. A
>> simple
>> >> > and
>> >> > > > > somewhat contrived example: `ConsumerRecord.toString` calls the
>> >> > `topic`
>> >> > > > > method. Someone overrides the `topic` method and it all works as
>> >> > > > expected.
>> >> > > > > In a subsequent release, we change `toString` to use the field
>> >> > directly
>> >> > > > > (like it's done for other fields like `key` and `value`) and it
>> >> will
>> >> > > > break
>> >> > > > > `toString` for this user. One may wonder: why would one
>> override a
>> >> > > method
>> >> > > > > like `topic`? That is a good question, but part of the exercise
>> is
>> >> > > > deciding
>> >> > > > > how we approach these issues. We could make the methods final
>> and
>> >> > > > eliminate
>> >> > > > > the possibility, we could document it so that users can choose
>> to
>> >> do
>> >> > > > weird
>> >> > > > > things if they want, etc.
>> >> > > > >
>> >> > > > > Another thing that is usually good to think about is the
>> >> expectation
>> >> > > for
>> >> > > > > `equals` and `hashCode`. What if subclasses implement them to
>> have
>> >> > > value
>> >> > > > > semantics instead of identity semantics. Is that OK or would it
>> >> break
>> >> > > > > things?
>> >> > > > >
>> >> > > > > Designing for implementation inheritance is generally complex
>> >> > although
>> >> > > > for
>> >> > > > > simple "record" like classes, it can be easier by following a
>> few
>> >> > > > > guidelines.
>> >> > > > >
>> >> > > > > Ismael
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Nacho - Ignacio Solis - isolis@igso.net
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Nacho - Ignacio Solis - isolis@igso.net
>> >
>>
>>
>>
>> --
>> Nacho - Ignacio Solis - isolis@igso.net
>>
--
Gwen Shapira
Product Manager | Confluent
650.450.2760 | @gwenshap
Follow us: Twitter | blog
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Ismael Juma <is...@juma.me.uk>.
OK, so it seems like there are no changes that break compatibility in the
0.10.1 branch since we offer no compatibility guarantees for logging
output. That's good. :)
About the removal of final, it happened in trunk and it doesn't seem like
anyone is still asking for it to be included in the 0.10.1 branch so it is
indeed not important for this bug fix release (I thought we had established
that quite a while ago).
Ismael
On Tue, Nov 29, 2016 at 9:35 PM, Ignacio Solis <is...@igso.net> wrote:
> Sorry, that was a hasty reply. There are also various logging things that
> change format. This could break parsers.
>
> None of them are important, my only argument is that the final keyword
> removal is not important either.
>
> Nacho
>
>
> On Tue, Nov 29, 2016 at 1:25 PM, Ignacio Solis <is...@igso.net> wrote:
>
> > https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=
> > 10cfc1628df024f7596d3af5c168fa90f59035ca
> >
> > On Tue, Nov 29, 2016 at 1:24 PM, Ismael Juma <is...@juma.me.uk> wrote:
> >
> >> Which changes break compatibility in the 0.10.1 branch? It would be good
> >> to
> >> fix before the release goes out.
> >>
> >> Ismael
> >>
> >> On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
> >>
> >> > Some of the changes in the 0.10.1 branch already are not bug fixes.
> Some
> >> > break compatibility.
> >> >
> >> > Having said that, at this level we should maintain a stable API and
> >> leave
> >> > any changes for real version bumps. This should be only a bugfix
> >> release.
> >> >
> >> > Nacho
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <is...@juma.me.uk>
> wrote:
> >> >
> >> > > I disagree, but let's discuss it another time and in a separate
> >> thread.
> >> > :)
> >> > >
> >> > > Ismael
> >> > >
> >> > > On Tue, Nov 29, 2016 at 4:30 PM, radai <ra...@gmail.com>
> >> > wrote:
> >> > >
> >> > > > designing kafka code for stable extensibility is a worthy and
> noble
> >> > > cause.
> >> > > > however, seeing as there are no such derivatives out in the wild
> >> yet i
> >> > > > think investing the effort right now is a bit premature from
> kafka's
> >> > pov.
> >> > > > I think its enough simply not to purposefully prevent such
> >> extensions.
> >> > > >
> >> > > > On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <is...@juma.me.uk>
> >> > wrote:
> >> > > >
> >> > > > > On Sat, Nov 26, 2016 at 11:08 PM, radai <
> >> radai.rosenblatt@gmail.com>
> >> > > > > wrote:
> >> > > > >
> >> > > > > > "compatibility guarantees that are expected by people who
> >> subclass
> >> > > > these
> >> > > > > > classes"
> >> > > > > >
> >> > > > > > sorry if this is not the best thread for this discussion, but
> I
> >> > just
> >> > > > > wanted
> >> > > > > > to pop in and say that since any subclassing of these will
> >> > obviously
> >> > > > not
> >> > > > > be
> >> > > > > > done within the kafka codebase - what guarantees are needed?
> >> > > > > >
> >> > > > >
> >> > > > > I elaborated a little in my other message in this thread. A
> simple
> >> > and
> >> > > > > somewhat contrived example: `ConsumerRecord.toString` calls the
> >> > `topic`
> >> > > > > method. Someone overrides the `topic` method and it all works as
> >> > > > expected.
> >> > > > > In a subsequent release, we change `toString` to use the field
> >> > directly
> >> > > > > (like it's done for other fields like `key` and `value`) and it
> >> will
> >> > > > break
> >> > > > > `toString` for this user. One may wonder: why would one
> override a
> >> > > method
> >> > > > > like `topic`? That is a good question, but part of the exercise
> is
> >> > > > deciding
> >> > > > > how we approach these issues. We could make the methods final
> and
> >> > > > eliminate
> >> > > > > the possibility, we could document it so that users can choose
> to
> >> do
> >> > > > weird
> >> > > > > things if they want, etc.
> >> > > > >
> >> > > > > Another thing that is usually good to think about is the
> >> expectation
> >> > > for
> >> > > > > `equals` and `hashCode`. What if subclasses implement them to
> have
> >> > > value
> >> > > > > semantics instead of identity semantics. Is that OK or would it
> >> break
> >> > > > > things?
> >> > > > >
> >> > > > > Designing for implementation inheritance is generally complex
> >> > although
> >> > > > for
> >> > > > > simple "record" like classes, it can be easier by following a
> few
> >> > > > > guidelines.
> >> > > > >
> >> > > > > Ismael
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Nacho - Ignacio Solis - isolis@igso.net
> >> >
> >>
> >
> >
> >
> > --
> > Nacho - Ignacio Solis - isolis@igso.net
> >
>
>
>
> --
> Nacho - Ignacio Solis - isolis@igso.net
>
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Ignacio Solis <is...@igso.net>.
Sorry, that was a hasty reply. There are also various logging things that
change format. This could break parsers.
None of them are important, my only argument is that the final keyword
removal is not important either.
Nacho
On Tue, Nov 29, 2016 at 1:25 PM, Ignacio Solis <is...@igso.net> wrote:
> https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=
> 10cfc1628df024f7596d3af5c168fa90f59035ca
>
> On Tue, Nov 29, 2016 at 1:24 PM, Ismael Juma <is...@juma.me.uk> wrote:
>
>> Which changes break compatibility in the 0.10.1 branch? It would be good
>> to
>> fix before the release goes out.
>>
>> Ismael
>>
>> On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
>>
>> > Some of the changes in the 0.10.1 branch already are not bug fixes. Some
>> > break compatibility.
>> >
>> > Having said that, at this level we should maintain a stable API and
>> leave
>> > any changes for real version bumps. This should be only a bugfix
>> release.
>> >
>> > Nacho
>> >
>> >
>> >
>> >
>> > On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <is...@juma.me.uk> wrote:
>> >
>> > > I disagree, but let's discuss it another time and in a separate
>> thread.
>> > :)
>> > >
>> > > Ismael
>> > >
>> > > On Tue, Nov 29, 2016 at 4:30 PM, radai <ra...@gmail.com>
>> > wrote:
>> > >
>> > > > designing kafka code for stable extensibility is a worthy and noble
>> > > cause.
>> > > > however, seeing as there are no such derivatives out in the wild
>> yet i
>> > > > think investing the effort right now is a bit premature from kafka's
>> > pov.
>> > > > I think its enough simply not to purposefully prevent such
>> extensions.
>> > > >
>> > > > On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <is...@juma.me.uk>
>> > wrote:
>> > > >
>> > > > > On Sat, Nov 26, 2016 at 11:08 PM, radai <
>> radai.rosenblatt@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > > "compatibility guarantees that are expected by people who
>> subclass
>> > > > these
>> > > > > > classes"
>> > > > > >
>> > > > > > sorry if this is not the best thread for this discussion, but I
>> > just
>> > > > > wanted
>> > > > > > to pop in and say that since any subclassing of these will
>> > obviously
>> > > > not
>> > > > > be
>> > > > > > done within the kafka codebase - what guarantees are needed?
>> > > > > >
>> > > > >
>> > > > > I elaborated a little in my other message in this thread. A simple
>> > and
>> > > > > somewhat contrived example: `ConsumerRecord.toString` calls the
>> > `topic`
>> > > > > method. Someone overrides the `topic` method and it all works as
>> > > > expected.
>> > > > > In a subsequent release, we change `toString` to use the field
>> > directly
>> > > > > (like it's done for other fields like `key` and `value`) and it
>> will
>> > > > break
>> > > > > `toString` for this user. One may wonder: why would one override a
>> > > method
>> > > > > like `topic`? That is a good question, but part of the exercise is
>> > > > deciding
>> > > > > how we approach these issues. We could make the methods final and
>> > > > eliminate
>> > > > > the possibility, we could document it so that users can choose to
>> do
>> > > > weird
>> > > > > things if they want, etc.
>> > > > >
>> > > > > Another thing that is usually good to think about is the
>> expectation
>> > > for
>> > > > > `equals` and `hashCode`. What if subclasses implement them to have
>> > > value
>> > > > > semantics instead of identity semantics. Is that OK or would it
>> break
>> > > > > things?
>> > > > >
>> > > > > Designing for implementation inheritance is generally complex
>> > although
>> > > > for
>> > > > > simple "record" like classes, it can be easier by following a few
>> > > > > guidelines.
>> > > > >
>> > > > > Ismael
>> > > > >
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Nacho - Ignacio Solis - isolis@igso.net
>> >
>>
>
>
>
> --
> Nacho - Ignacio Solis - isolis@igso.net
>
--
Nacho - Ignacio Solis - isolis@igso.net
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Ignacio Solis <is...@igso.net>.
https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=10cfc1628df024f7596d3af5c168fa90f59035ca
On Tue, Nov 29, 2016 at 1:24 PM, Ismael Juma <is...@juma.me.uk> wrote:
> Which changes break compatibility in the 0.10.1 branch? It would be good to
> fix before the release goes out.
>
> Ismael
>
> On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
>
> > Some of the changes in the 0.10.1 branch already are not bug fixes. Some
> > break compatibility.
> >
> > Having said that, at this level we should maintain a stable API and leave
> > any changes for real version bumps. This should be only a bugfix
> release.
> >
> > Nacho
> >
> >
> >
> >
> > On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <is...@juma.me.uk> wrote:
> >
> > > I disagree, but let's discuss it another time and in a separate thread.
> > :)
> > >
> > > Ismael
> > >
> > > On Tue, Nov 29, 2016 at 4:30 PM, radai <ra...@gmail.com>
> > wrote:
> > >
> > > > designing kafka code for stable extensibility is a worthy and noble
> > > cause.
> > > > however, seeing as there are no such derivatives out in the wild yet
> i
> > > > think investing the effort right now is a bit premature from kafka's
> > pov.
> > > > I think its enough simply not to purposefully prevent such
> extensions.
> > > >
> > > > On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <is...@juma.me.uk>
> > wrote:
> > > >
> > > > > On Sat, Nov 26, 2016 at 11:08 PM, radai <
> radai.rosenblatt@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > "compatibility guarantees that are expected by people who
> subclass
> > > > these
> > > > > > classes"
> > > > > >
> > > > > > sorry if this is not the best thread for this discussion, but I
> > just
> > > > > wanted
> > > > > > to pop in and say that since any subclassing of these will
> > obviously
> > > > not
> > > > > be
> > > > > > done within the kafka codebase - what guarantees are needed?
> > > > > >
> > > > >
> > > > > I elaborated a little in my other message in this thread. A simple
> > and
> > > > > somewhat contrived example: `ConsumerRecord.toString` calls the
> > `topic`
> > > > > method. Someone overrides the `topic` method and it all works as
> > > > expected.
> > > > > In a subsequent release, we change `toString` to use the field
> > directly
> > > > > (like it's done for other fields like `key` and `value`) and it
> will
> > > > break
> > > > > `toString` for this user. One may wonder: why would one override a
> > > method
> > > > > like `topic`? That is a good question, but part of the exercise is
> > > > deciding
> > > > > how we approach these issues. We could make the methods final and
> > > > eliminate
> > > > > the possibility, we could document it so that users can choose to
> do
> > > > weird
> > > > > things if they want, etc.
> > > > >
> > > > > Another thing that is usually good to think about is the
> expectation
> > > for
> > > > > `equals` and `hashCode`. What if subclasses implement them to have
> > > value
> > > > > semantics instead of identity semantics. Is that OK or would it
> break
> > > > > things?
> > > > >
> > > > > Designing for implementation inheritance is generally complex
> > although
> > > > for
> > > > > simple "record" like classes, it can be easier by following a few
> > > > > guidelines.
> > > > >
> > > > > Ismael
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Nacho - Ignacio Solis - isolis@igso.net
> >
>
--
Nacho - Ignacio Solis - isolis@igso.net
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Ismael Juma <is...@juma.me.uk>.
Which changes break compatibility in the 0.10.1 branch? It would be good to
fix before the release goes out.
Ismael
On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
> Some of the changes in the 0.10.1 branch already are not bug fixes. Some
> break compatibility.
>
> Having said that, at this level we should maintain a stable API and leave
> any changes for real version bumps. This should be only a bugfix release.
>
> Nacho
>
>
>
>
> On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <is...@juma.me.uk> wrote:
>
> > I disagree, but let's discuss it another time and in a separate thread.
> :)
> >
> > Ismael
> >
> > On Tue, Nov 29, 2016 at 4:30 PM, radai <ra...@gmail.com>
> wrote:
> >
> > > designing kafka code for stable extensibility is a worthy and noble
> > cause.
> > > however, seeing as there are no such derivatives out in the wild yet i
> > > think investing the effort right now is a bit premature from kafka's
> pov.
> > > I think its enough simply not to purposefully prevent such extensions.
> > >
> > > On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <is...@juma.me.uk>
> wrote:
> > >
> > > > On Sat, Nov 26, 2016 at 11:08 PM, radai <ra...@gmail.com>
> > > > wrote:
> > > >
> > > > > "compatibility guarantees that are expected by people who subclass
> > > these
> > > > > classes"
> > > > >
> > > > > sorry if this is not the best thread for this discussion, but I
> just
> > > > wanted
> > > > > to pop in and say that since any subclassing of these will
> obviously
> > > not
> > > > be
> > > > > done within the kafka codebase - what guarantees are needed?
> > > > >
> > > >
> > > > I elaborated a little in my other message in this thread. A simple
> and
> > > > somewhat contrived example: `ConsumerRecord.toString` calls the
> `topic`
> > > > method. Someone overrides the `topic` method and it all works as
> > > expected.
> > > > In a subsequent release, we change `toString` to use the field
> directly
> > > > (like it's done for other fields like `key` and `value`) and it will
> > > break
> > > > `toString` for this user. One may wonder: why would one override a
> > method
> > > > like `topic`? That is a good question, but part of the exercise is
> > > deciding
> > > > how we approach these issues. We could make the methods final and
> > > eliminate
> > > > the possibility, we could document it so that users can choose to do
> > > weird
> > > > things if they want, etc.
> > > >
> > > > Another thing that is usually good to think about is the expectation
> > for
> > > > `equals` and `hashCode`. What if subclasses implement them to have
> > value
> > > > semantics instead of identity semantics. Is that OK or would it break
> > > > things?
> > > >
> > > > Designing for implementation inheritance is generally complex
> although
> > > for
> > > > simple "record" like classes, it can be easier by following a few
> > > > guidelines.
> > > >
> > > > Ismael
> > > >
> > >
> >
>
>
>
> --
> Nacho - Ignacio Solis - isolis@igso.net
>
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Ignacio Solis <is...@igso.net>.
Some of the changes in the 0.10.1 branch already are not bug fixes. Some
break compatibility.
Having said that, at this level we should maintain a stable API and leave
any changes for real version bumps. This should be only a bugfix release.
Nacho
On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <is...@juma.me.uk> wrote:
> I disagree, but let's discuss it another time and in a separate thread. :)
>
> Ismael
>
> On Tue, Nov 29, 2016 at 4:30 PM, radai <ra...@gmail.com> wrote:
>
> > designing kafka code for stable extensibility is a worthy and noble
> cause.
> > however, seeing as there are no such derivatives out in the wild yet i
> > think investing the effort right now is a bit premature from kafka's pov.
> > I think its enough simply not to purposefully prevent such extensions.
> >
> > On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <is...@juma.me.uk> wrote:
> >
> > > On Sat, Nov 26, 2016 at 11:08 PM, radai <ra...@gmail.com>
> > > wrote:
> > >
> > > > "compatibility guarantees that are expected by people who subclass
> > these
> > > > classes"
> > > >
> > > > sorry if this is not the best thread for this discussion, but I just
> > > wanted
> > > > to pop in and say that since any subclassing of these will obviously
> > not
> > > be
> > > > done within the kafka codebase - what guarantees are needed?
> > > >
> > >
> > > I elaborated a little in my other message in this thread. A simple and
> > > somewhat contrived example: `ConsumerRecord.toString` calls the `topic`
> > > method. Someone overrides the `topic` method and it all works as
> > expected.
> > > In a subsequent release, we change `toString` to use the field directly
> > > (like it's done for other fields like `key` and `value`) and it will
> > break
> > > `toString` for this user. One may wonder: why would one override a
> method
> > > like `topic`? That is a good question, but part of the exercise is
> > deciding
> > > how we approach these issues. We could make the methods final and
> > eliminate
> > > the possibility, we could document it so that users can choose to do
> > weird
> > > things if they want, etc.
> > >
> > > Another thing that is usually good to think about is the expectation
> for
> > > `equals` and `hashCode`. What if subclasses implement them to have
> value
> > > semantics instead of identity semantics. Is that OK or would it break
> > > things?
> > >
> > > Designing for implementation inheritance is generally complex although
> > for
> > > simple "record" like classes, it can be easier by following a few
> > > guidelines.
> > >
> > > Ismael
> > >
> >
>
--
Nacho - Ignacio Solis - isolis@igso.net
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Ismael Juma <is...@juma.me.uk>.
I disagree, but let's discuss it another time and in a separate thread. :)
Ismael
On Tue, Nov 29, 2016 at 4:30 PM, radai <ra...@gmail.com> wrote:
> designing kafka code for stable extensibility is a worthy and noble cause.
> however, seeing as there are no such derivatives out in the wild yet i
> think investing the effort right now is a bit premature from kafka's pov.
> I think its enough simply not to purposefully prevent such extensions.
>
> On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <is...@juma.me.uk> wrote:
>
> > On Sat, Nov 26, 2016 at 11:08 PM, radai <ra...@gmail.com>
> > wrote:
> >
> > > "compatibility guarantees that are expected by people who subclass
> these
> > > classes"
> > >
> > > sorry if this is not the best thread for this discussion, but I just
> > wanted
> > > to pop in and say that since any subclassing of these will obviously
> not
> > be
> > > done within the kafka codebase - what guarantees are needed?
> > >
> >
> > I elaborated a little in my other message in this thread. A simple and
> > somewhat contrived example: `ConsumerRecord.toString` calls the `topic`
> > method. Someone overrides the `topic` method and it all works as
> expected.
> > In a subsequent release, we change `toString` to use the field directly
> > (like it's done for other fields like `key` and `value`) and it will
> break
> > `toString` for this user. One may wonder: why would one override a method
> > like `topic`? That is a good question, but part of the exercise is
> deciding
> > how we approach these issues. We could make the methods final and
> eliminate
> > the possibility, we could document it so that users can choose to do
> weird
> > things if they want, etc.
> >
> > Another thing that is usually good to think about is the expectation for
> > `equals` and `hashCode`. What if subclasses implement them to have value
> > semantics instead of identity semantics. Is that OK or would it break
> > things?
> >
> > Designing for implementation inheritance is generally complex although
> for
> > simple "record" like classes, it can be easier by following a few
> > guidelines.
> >
> > Ismael
> >
>
Re: [DISCUSS] 0.10.1.1 Plan
Posted by radai <ra...@gmail.com>.
designing kafka code for stable extensibility is a worthy and noble cause.
however, seeing as there are no such derivatives out in the wild yet i
think investing the effort right now is a bit premature from kafka's pov.
I think its enough simply not to purposefully prevent such extensions.
On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <is...@juma.me.uk> wrote:
> On Sat, Nov 26, 2016 at 11:08 PM, radai <ra...@gmail.com>
> wrote:
>
> > "compatibility guarantees that are expected by people who subclass these
> > classes"
> >
> > sorry if this is not the best thread for this discussion, but I just
> wanted
> > to pop in and say that since any subclassing of these will obviously not
> be
> > done within the kafka codebase - what guarantees are needed?
> >
>
> I elaborated a little in my other message in this thread. A simple and
> somewhat contrived example: `ConsumerRecord.toString` calls the `topic`
> method. Someone overrides the `topic` method and it all works as expected.
> In a subsequent release, we change `toString` to use the field directly
> (like it's done for other fields like `key` and `value`) and it will break
> `toString` for this user. One may wonder: why would one override a method
> like `topic`? That is a good question, but part of the exercise is deciding
> how we approach these issues. We could make the methods final and eliminate
> the possibility, we could document it so that users can choose to do weird
> things if they want, etc.
>
> Another thing that is usually good to think about is the expectation for
> `equals` and `hashCode`. What if subclasses implement them to have value
> semantics instead of identity semantics. Is that OK or would it break
> things?
>
> Designing for implementation inheritance is generally complex although for
> simple "record" like classes, it can be easier by following a few
> guidelines.
>
> Ismael
>
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Ismael Juma <is...@juma.me.uk>.
On Sat, Nov 26, 2016 at 11:08 PM, radai <ra...@gmail.com> wrote:
> "compatibility guarantees that are expected by people who subclass these
> classes"
>
> sorry if this is not the best thread for this discussion, but I just wanted
> to pop in and say that since any subclassing of these will obviously not be
> done within the kafka codebase - what guarantees are needed?
>
I elaborated a little in my other message in this thread. A simple and
somewhat contrived example: `ConsumerRecord.toString` calls the `topic`
method. Someone overrides the `topic` method and it all works as expected.
In a subsequent release, we change `toString` to use the field directly
(like it's done for other fields like `key` and `value`) and it will break
`toString` for this user. One may wonder: why would one override a method
like `topic`? That is a good question, but part of the exercise is deciding
how we approach these issues. We could make the methods final and eliminate
the possibility, we could document it so that users can choose to do weird
things if they want, etc.
Another thing that is usually good to think about is the expectation for
`equals` and `hashCode`. What if subclasses implement them to have value
semantics instead of identity semantics. Is that OK or would it break
things?
Designing for implementation inheritance is generally complex although for
simple "record" like classes, it can be easier by following a few
guidelines.
Ismael
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Bernard Leach <le...@bouncycastle.org>.
Getting out 0.10.1.1 quickly makes a lot of sense so perhaps the answer to the quality concern is to not publish the 2.12 tgz and instead simply publish the artifacts to maven central allowing the scala community to become a part of that quality process. That way when the 0.10.2.0 release swings around there will already be a level of maturity with 2.12.
On 29 Nov 2016, at 06:17, Guozhang Wang <wa...@gmail.com> wrote:
>
> @Radai
>
> I think Ismael's point is that people who coded their applications against
> 0.10.1.1 should be able to swipe in the 0.10.1.0 jar without breaking the
> code (in practice maybe it is more likely the reverse scenario, that people
> coded against 0.10.1.0 and trying to swipe in a newer 0.10.1.1).
>
> @Bernard Leach
>
> I agree that having Scala 2.12 support as early as possible than next Feb
> can help the Scala community who's using Kafka. However, the downside is
> that it may increase our release cycles for this bug-fix release as we need
> to add more validation process to make sure that builds with Scala12 works
> perfectly, while we are trying to make 0.10.1.1 out asap.
>
>
> Guozhang
>
>
> On Sun, Nov 27, 2016 at 5:16 PM, Bernard Leach <le...@bouncycastle.org>
> wrote:
>
>> I guess bugs are in the eye of the beholder; I’d really like to see
>> KAFKA-4438 addressed as a patch release - the bug being "I can’t currently
>> build any scala 2.12 projects with Kafka as a dependency". There’s a PR
>> ready to go for the branch that has already been accepted to trunk and this
>> Ismael has addressed the risk issue by making the 2.12 not part of the
>> default build.
>>
>> There are a number of downstream projects awaiting kafka scala 2.12
>> binaries so they can publish their own so getting this addressed before
>> February would really help push along the availability of 2.12 compatible
>> libraries.
>>
>> cheers,
>> bern.
>>
>>> On 27 Nov 2016, at 10:08, radai <ra...@gmail.com> wrote:
>>>
>>> "compatibility guarantees that are expected by people who subclass these
>>> classes"
>>>
>>> sorry if this is not the best thread for this discussion, but I just
>> wanted
>>> to pop in and say that since any subclassing of these will obviously not
>> be
>>> done within the kafka codebase - what guarantees are needed?
>>>
>>> On Fri, Nov 25, 2016 at 11:13 PM, Michael Pearce <Mi...@ig.com>
>>> wrote:
>>>
>>>> As agreed that this should be purely a bug fix release for stability.
>>>>
>>>>
>>>> I'd like to flag then we shouldn't be adding / merging in any Jira's
>> that
>>>> are not bugs.
>>>>
>>>> e.g. KAFKA-4438
>>>>
>>>>
>>>> ________________________________________
>>>> From: ismaelj@gmail.com <is...@gmail.com> on behalf of Ismael Juma <
>>>> ismael@juma.me.uk>
>>>> Sent: Friday, November 25, 2016 11:43 AM
>>>> To: dev@kafka.apache.org
>>>> Subject: Re: [DISCUSS] 0.10.1.1 Plan
>>>>
>>>> Good, seems like we are in agreement about sticking to bug fixes for
>>>> 0.10.1.1.
>>>>
>>>> Regarding the removal of final, I understand that it doesn't break
>>>> backwards binary compatibility (it does break forwards compatibility and
>>>> hence why it's more suited for feature releases; these are the same
>> rules
>>>> followed by the JDK and Scala).
>>>>
>>>> It's probably best to discuss this in another thread, but to clarify:
>> the
>>>> point I was making is that once you make a class non final, maintaining
>>>> compatibility becomes more complex. You have to take into account that
>>>> methods could have been overridden, for example. As such, some thought
>>>> should be given to the scenarios under which classes can be extended,
>> how
>>>> we will ensure that we can evolve the class without breaking users,
>> whether
>>>> we want to make some methods final, whether we should add some
>>>> documentation guiding users regarding good/bad examples of inheritance
>>>> versus composition for these classes and so on. This is particularly
>>>> important for core client classes exposed by the consumer and producer
>> and
>>>> it is the approach taken by projects that have a good track record with
>>>> regards to maintaining compatibility for long periods of time. I didn't
>> see
>>>> much discussion or reasoning along the lines above for the
>>>> ProducerRecord/ConsumerRecord change and hence my comment (even if it
>> may
>>>> actually me a good change once all is considered).
>>>>
>>>> Ismael
>>>>
>>>> On Thu, Nov 24, 2016 at 7:56 PM, Michael Pearce <Mi...@ig.com>
>>>> wrote:
>>>>
>>>>> +1 it would be nice, and as is less restrive would not cause any issue.
>>>>>
>>>>> Saying that agree this is a fix build not a feature build.
>>>>>
>>>>> Sent using OWA for iPhone
>>>>> ________________________________________
>>>>> From: Rajini Sivaram <ra...@googlemail.com>
>>>>> Sent: Thursday, November 24, 2016 12:17:13 PM
>>>>> To: dev@kafka.apache.org
>>>>> Subject: Re: [DISCUSS] 0.10.1.1 Plan
>>>>>
>>>>> Hi Ismael,
>>>>>
>>>>> OK, I do agree with you. At the moment, our code wraps these three
>>>> classes
>>>>> since they can't be extended. I recently noticed that two of the three
>>>> are
>>>>> now non-final in trunk. If all three were made non-final, we would like
>>>> to
>>>>> extend them,
>>>>>
>>>>> According to the Java specification:
>>>>>
>>>>> *Changing a class that is declared final to no longer be
>>>>> declared final does not break compatibility with pre-existing
>> binaries.*
>>>>>
>>>>>
>>>>> So it shouldn't break anything. Perhaps that is the reason why
>> KAFKA-4250
>>>>> was merged (I hadn't even noticed it). It is not critical, so I am ok
>>>> with
>>>>> it not being in the patch release.
>>>>>
>>>>>
>>>>> On Thu, Nov 24, 2016 at 11:43 AM, Ismael Juma <is...@gmail.com>
>> wrote:
>>>>>
>>>>>> Hi Rajini,
>>>>>>
>>>>>> I think we should avoid making changes like that in patch releases as
>>>> it
>>>>>> means that code that compiles with 0.10.1.1 may not compile with
>>>>> 0.10.1.0.
>>>>>> Since we now have frequent time based releases, I think it makes sense
>>>>> for
>>>>>> patch releases to only include bug fixes and test stability fixes.
>>>>>>
>>>>>> About the specific changes that you mention, I didn't see a discussion
>>>>>> about compatibility guarantees that are expected by people who
>> subclass
>>>>>> these classes so I think it was a bit premature to merge the
>>>>> ProducerRecord
>>>>>> and ConsumerRecord final removal change.
>>>>>>
>>>>>> Ismael
>>>>>>
>>>>>> On 24 Nov 2016 10:26 am, "Rajini Sivaram" <
>>>> rajinisivaram@googlemail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Can we add KAFKA-4440 and KAFKA-4250 to the the list? They make
>>>>>>> ProducerRecord/ConsumerRecord/RecordMetadata non-final so that they
>>>>> can
>>>>>> be
>>>>>>> extended. The changes have minimal impact on the codebase, but will
>>>>>> really
>>>>>>> help when implementing other producers/consumers. It is not a
>>>> bug-fix,
>>>>>> but
>>>>>>> if we are going to make the change, it will be good to have it in a
>>>>>> release
>>>>>>> soon.
>>>>>>>
>>>>>>> Thank you,
>>>>>>>
>>>>>>> Rajini
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 24, 2016 at 4:36 AM, Bernard Leach <
>>>>> leachbj@bouncycastle.org
>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Guozhang,
>>>>>>>>
>>>>>>>> I have added KAFKA-4438 to that list as that would enable
>>>> publishing
>>>>>> the
>>>>>>>> scala 2.12 builds of 0.10.1.1. There are other tasks in order to
>>>>>>> actually
>>>>>>>> publish a 2.12 but merging that change would enable that process.
>>>>>>> There’s
>>>>>>>> a corresponding PR on github that consists of a cherry-pick of the
>>>>>>>> corresponding change from trunk.
>>>>>>>>
>>>>>>>> cheers,
>>>>>>>> bern
>>>>>>>>
>>>>>>>>> On 24 Nov 2016, at 06:58, Guozhang Wang <wa...@gmail.com>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi everyone,
>>>>>>>>>
>>>>>>>>> We have resolved 15 JIRAs including a few critical bugs in the
>>>>> 0.10.1
>>>>>>>>> branch since 0.10.1.0 was released so I'd like to propose to
>>>>> release
>>>>>>>>> 0.10.1.1 soon:
>>>>>>>>>
>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%
>>>>>>>> 3D%20KAFKA%20AND%20resolution%20%3D%20Fixed%20AND%
>>>>>>>> 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
>>>>>>>> 20DESC%2C%20key%20DESC
>>>>>>>>>
>>>>>>>>> There are still a few outstanding issues that are not unresolved
>>>>> and
>>>>>>> have
>>>>>>>>> 0.10.1.1 as the target version:
>>>>>>>>>
>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%
>>>>>>>> 3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%
>>>>>>>> 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
>>>>>>>> 20DESC%2C%20key%20DESC
>>>>>>>>>
>>>>>>>>> Once we have resolved these issues I will start the release
>>>>> process.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> -- Guozhang
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>>
>>>>>>> Rajini
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>>
>>>>> Rajini
>>>>> The information contained in this email is strictly confidential and
>> for
>>>>> the use of the addressee only, unless otherwise indicated. If you are
>> not
>>>>> the intended recipient, please do not read, copy, use or disclose to
>>>> others
>>>>> this message or any attachment. Please also notify the sender by
>> replying
>>>>> to this email or by telephone (+44(020 7896 0011) and then delete the
>>>>> email and any copies of it. Opinions, conclusion (etc) that do not
>> relate
>>>>> to the official business of this company shall be understood as neither
>>>>> given nor endorsed by it. IG is a trading name of IG Markets Limited (a
>>>>> company registered in England and Wales, company number 04008957) and
>> IG
>>>>> Index Limited (a company registered in England and Wales, company
>> number
>>>>> 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill,
>>>>> London EC4R 2YA. Both IG Markets Limited (register number 195355) and
>> IG
>>>>> Index Limited (register number 114059) are authorised and regulated by
>>>> the
>>>>> Financial Conduct Authority.
>>>>>
>>>> The information contained in this email is strictly confidential and for
>>>> the use of the addressee only, unless otherwise indicated. If you are
>> not
>>>> the intended recipient, please do not read, copy, use or disclose to
>> others
>>>> this message or any attachment. Please also notify the sender by
>> replying
>>>> to this email or by telephone (+44(020 7896 0011) and then delete the
>> email
>>>> and any copies of it. Opinions, conclusion (etc) that do not relate to
>> the
>>>> official business of this company shall be understood as neither given
>> nor
>>>> endorsed by it. IG is a trading name of IG Markets Limited (a company
>>>> registered in England and Wales, company number 04008957) and IG Index
>>>> Limited (a company registered in England and Wales, company number
>>>> 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill,
>>>> London EC4R 2YA. Both IG Markets Limited (register number 195355) and IG
>>>> Index Limited (register number 114059) are authorised and regulated by
>> the
>>>> Financial Conduct Authority.
>>>>
>>
>>
>
>
> --
> -- Guozhang
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Guozhang Wang <wa...@gmail.com>.
@Radai
I think Ismael's point is that people who coded their applications against
0.10.1.1 should be able to swipe in the 0.10.1.0 jar without breaking the
code (in practice maybe it is more likely the reverse scenario, that people
coded against 0.10.1.0 and trying to swipe in a newer 0.10.1.1).
@Bernard Leach
I agree that having Scala 2.12 support as early as possible than next Feb
can help the Scala community who's using Kafka. However, the downside is
that it may increase our release cycles for this bug-fix release as we need
to add more validation process to make sure that builds with Scala12 works
perfectly, while we are trying to make 0.10.1.1 out asap.
Guozhang
On Sun, Nov 27, 2016 at 5:16 PM, Bernard Leach <le...@bouncycastle.org>
wrote:
> I guess bugs are in the eye of the beholder; I’d really like to see
> KAFKA-4438 addressed as a patch release - the bug being "I can’t currently
> build any scala 2.12 projects with Kafka as a dependency". There’s a PR
> ready to go for the branch that has already been accepted to trunk and this
> Ismael has addressed the risk issue by making the 2.12 not part of the
> default build.
>
> There are a number of downstream projects awaiting kafka scala 2.12
> binaries so they can publish their own so getting this addressed before
> February would really help push along the availability of 2.12 compatible
> libraries.
>
> cheers,
> bern.
>
> > On 27 Nov 2016, at 10:08, radai <ra...@gmail.com> wrote:
> >
> > "compatibility guarantees that are expected by people who subclass these
> > classes"
> >
> > sorry if this is not the best thread for this discussion, but I just
> wanted
> > to pop in and say that since any subclassing of these will obviously not
> be
> > done within the kafka codebase - what guarantees are needed?
> >
> > On Fri, Nov 25, 2016 at 11:13 PM, Michael Pearce <Mi...@ig.com>
> > wrote:
> >
> >> As agreed that this should be purely a bug fix release for stability.
> >>
> >>
> >> I'd like to flag then we shouldn't be adding / merging in any Jira's
> that
> >> are not bugs.
> >>
> >> e.g. KAFKA-4438
> >>
> >>
> >> ________________________________________
> >> From: ismaelj@gmail.com <is...@gmail.com> on behalf of Ismael Juma <
> >> ismael@juma.me.uk>
> >> Sent: Friday, November 25, 2016 11:43 AM
> >> To: dev@kafka.apache.org
> >> Subject: Re: [DISCUSS] 0.10.1.1 Plan
> >>
> >> Good, seems like we are in agreement about sticking to bug fixes for
> >> 0.10.1.1.
> >>
> >> Regarding the removal of final, I understand that it doesn't break
> >> backwards binary compatibility (it does break forwards compatibility and
> >> hence why it's more suited for feature releases; these are the same
> rules
> >> followed by the JDK and Scala).
> >>
> >> It's probably best to discuss this in another thread, but to clarify:
> the
> >> point I was making is that once you make a class non final, maintaining
> >> compatibility becomes more complex. You have to take into account that
> >> methods could have been overridden, for example. As such, some thought
> >> should be given to the scenarios under which classes can be extended,
> how
> >> we will ensure that we can evolve the class without breaking users,
> whether
> >> we want to make some methods final, whether we should add some
> >> documentation guiding users regarding good/bad examples of inheritance
> >> versus composition for these classes and so on. This is particularly
> >> important for core client classes exposed by the consumer and producer
> and
> >> it is the approach taken by projects that have a good track record with
> >> regards to maintaining compatibility for long periods of time. I didn't
> see
> >> much discussion or reasoning along the lines above for the
> >> ProducerRecord/ConsumerRecord change and hence my comment (even if it
> may
> >> actually me a good change once all is considered).
> >>
> >> Ismael
> >>
> >> On Thu, Nov 24, 2016 at 7:56 PM, Michael Pearce <Mi...@ig.com>
> >> wrote:
> >>
> >>> +1 it would be nice, and as is less restrive would not cause any issue.
> >>>
> >>> Saying that agree this is a fix build not a feature build.
> >>>
> >>> Sent using OWA for iPhone
> >>> ________________________________________
> >>> From: Rajini Sivaram <ra...@googlemail.com>
> >>> Sent: Thursday, November 24, 2016 12:17:13 PM
> >>> To: dev@kafka.apache.org
> >>> Subject: Re: [DISCUSS] 0.10.1.1 Plan
> >>>
> >>> Hi Ismael,
> >>>
> >>> OK, I do agree with you. At the moment, our code wraps these three
> >> classes
> >>> since they can't be extended. I recently noticed that two of the three
> >> are
> >>> now non-final in trunk. If all three were made non-final, we would like
> >> to
> >>> extend them,
> >>>
> >>> According to the Java specification:
> >>>
> >>> *Changing a class that is declared final to no longer be
> >>> declared final does not break compatibility with pre-existing
> binaries.*
> >>>
> >>>
> >>> So it shouldn't break anything. Perhaps that is the reason why
> KAFKA-4250
> >>> was merged (I hadn't even noticed it). It is not critical, so I am ok
> >> with
> >>> it not being in the patch release.
> >>>
> >>>
> >>> On Thu, Nov 24, 2016 at 11:43 AM, Ismael Juma <is...@gmail.com>
> wrote:
> >>>
> >>>> Hi Rajini,
> >>>>
> >>>> I think we should avoid making changes like that in patch releases as
> >> it
> >>>> means that code that compiles with 0.10.1.1 may not compile with
> >>> 0.10.1.0.
> >>>> Since we now have frequent time based releases, I think it makes sense
> >>> for
> >>>> patch releases to only include bug fixes and test stability fixes.
> >>>>
> >>>> About the specific changes that you mention, I didn't see a discussion
> >>>> about compatibility guarantees that are expected by people who
> subclass
> >>>> these classes so I think it was a bit premature to merge the
> >>> ProducerRecord
> >>>> and ConsumerRecord final removal change.
> >>>>
> >>>> Ismael
> >>>>
> >>>> On 24 Nov 2016 10:26 am, "Rajini Sivaram" <
> >> rajinisivaram@googlemail.com>
> >>>> wrote:
> >>>>
> >>>>> Can we add KAFKA-4440 and KAFKA-4250 to the the list? They make
> >>>>> ProducerRecord/ConsumerRecord/RecordMetadata non-final so that they
> >>> can
> >>>> be
> >>>>> extended. The changes have minimal impact on the codebase, but will
> >>>> really
> >>>>> help when implementing other producers/consumers. It is not a
> >> bug-fix,
> >>>> but
> >>>>> if we are going to make the change, it will be good to have it in a
> >>>> release
> >>>>> soon.
> >>>>>
> >>>>> Thank you,
> >>>>>
> >>>>> Rajini
> >>>>>
> >>>>>
> >>>>> On Thu, Nov 24, 2016 at 4:36 AM, Bernard Leach <
> >>> leachbj@bouncycastle.org
> >>>>>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi Guozhang,
> >>>>>>
> >>>>>> I have added KAFKA-4438 to that list as that would enable
> >> publishing
> >>>> the
> >>>>>> scala 2.12 builds of 0.10.1.1. There are other tasks in order to
> >>>>> actually
> >>>>>> publish a 2.12 but merging that change would enable that process.
> >>>>> There’s
> >>>>>> a corresponding PR on github that consists of a cherry-pick of the
> >>>>>> corresponding change from trunk.
> >>>>>>
> >>>>>> cheers,
> >>>>>> bern
> >>>>>>
> >>>>>>> On 24 Nov 2016, at 06:58, Guozhang Wang <wa...@gmail.com>
> >>> wrote:
> >>>>>>>
> >>>>>>> Hi everyone,
> >>>>>>>
> >>>>>>> We have resolved 15 JIRAs including a few critical bugs in the
> >>> 0.10.1
> >>>>>>> branch since 0.10.1.0 was released so I'd like to propose to
> >>> release
> >>>>>>> 0.10.1.1 soon:
> >>>>>>>
> >>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%
> >>>>>> 3D%20KAFKA%20AND%20resolution%20%3D%20Fixed%20AND%
> >>>>>> 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> >>>>>> 20DESC%2C%20key%20DESC
> >>>>>>>
> >>>>>>> There are still a few outstanding issues that are not unresolved
> >>> and
> >>>>> have
> >>>>>>> 0.10.1.1 as the target version:
> >>>>>>>
> >>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%
> >>>>>> 3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%
> >>>>>> 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> >>>>>> 20DESC%2C%20key%20DESC
> >>>>>>>
> >>>>>>> Once we have resolved these issues I will start the release
> >>> process.
> >>>>>>>
> >>>>>>> --
> >>>>>>> -- Guozhang
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Regards,
> >>>>>
> >>>>> Rajini
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Regards,
> >>>
> >>> Rajini
> >>> The information contained in this email is strictly confidential and
> for
> >>> the use of the addressee only, unless otherwise indicated. If you are
> not
> >>> the intended recipient, please do not read, copy, use or disclose to
> >> others
> >>> this message or any attachment. Please also notify the sender by
> replying
> >>> to this email or by telephone (+44(020 7896 0011) and then delete the
> >>> email and any copies of it. Opinions, conclusion (etc) that do not
> relate
> >>> to the official business of this company shall be understood as neither
> >>> given nor endorsed by it. IG is a trading name of IG Markets Limited (a
> >>> company registered in England and Wales, company number 04008957) and
> IG
> >>> Index Limited (a company registered in England and Wales, company
> number
> >>> 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill,
> >>> London EC4R 2YA. Both IG Markets Limited (register number 195355) and
> IG
> >>> Index Limited (register number 114059) are authorised and regulated by
> >> the
> >>> Financial Conduct Authority.
> >>>
> >> The information contained in this email is strictly confidential and for
> >> the use of the addressee only, unless otherwise indicated. If you are
> not
> >> the intended recipient, please do not read, copy, use or disclose to
> others
> >> this message or any attachment. Please also notify the sender by
> replying
> >> to this email or by telephone (+44(020 7896 0011) and then delete the
> email
> >> and any copies of it. Opinions, conclusion (etc) that do not relate to
> the
> >> official business of this company shall be understood as neither given
> nor
> >> endorsed by it. IG is a trading name of IG Markets Limited (a company
> >> registered in England and Wales, company number 04008957) and IG Index
> >> Limited (a company registered in England and Wales, company number
> >> 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill,
> >> London EC4R 2YA. Both IG Markets Limited (register number 195355) and IG
> >> Index Limited (register number 114059) are authorised and regulated by
> the
> >> Financial Conduct Authority.
> >>
>
>
--
-- Guozhang
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Bernard Leach <le...@bouncycastle.org>.
I guess bugs are in the eye of the beholder; I’d really like to see KAFKA-4438 addressed as a patch release - the bug being "I can’t currently build any scala 2.12 projects with Kafka as a dependency". There’s a PR ready to go for the branch that has already been accepted to trunk and this Ismael has addressed the risk issue by making the 2.12 not part of the default build.
There are a number of downstream projects awaiting kafka scala 2.12 binaries so they can publish their own so getting this addressed before February would really help push along the availability of 2.12 compatible libraries.
cheers,
bern.
> On 27 Nov 2016, at 10:08, radai <ra...@gmail.com> wrote:
>
> "compatibility guarantees that are expected by people who subclass these
> classes"
>
> sorry if this is not the best thread for this discussion, but I just wanted
> to pop in and say that since any subclassing of these will obviously not be
> done within the kafka codebase - what guarantees are needed?
>
> On Fri, Nov 25, 2016 at 11:13 PM, Michael Pearce <Mi...@ig.com>
> wrote:
>
>> As agreed that this should be purely a bug fix release for stability.
>>
>>
>> I'd like to flag then we shouldn't be adding / merging in any Jira's that
>> are not bugs.
>>
>> e.g. KAFKA-4438
>>
>>
>> ________________________________________
>> From: ismaelj@gmail.com <is...@gmail.com> on behalf of Ismael Juma <
>> ismael@juma.me.uk>
>> Sent: Friday, November 25, 2016 11:43 AM
>> To: dev@kafka.apache.org
>> Subject: Re: [DISCUSS] 0.10.1.1 Plan
>>
>> Good, seems like we are in agreement about sticking to bug fixes for
>> 0.10.1.1.
>>
>> Regarding the removal of final, I understand that it doesn't break
>> backwards binary compatibility (it does break forwards compatibility and
>> hence why it's more suited for feature releases; these are the same rules
>> followed by the JDK and Scala).
>>
>> It's probably best to discuss this in another thread, but to clarify: the
>> point I was making is that once you make a class non final, maintaining
>> compatibility becomes more complex. You have to take into account that
>> methods could have been overridden, for example. As such, some thought
>> should be given to the scenarios under which classes can be extended, how
>> we will ensure that we can evolve the class without breaking users, whether
>> we want to make some methods final, whether we should add some
>> documentation guiding users regarding good/bad examples of inheritance
>> versus composition for these classes and so on. This is particularly
>> important for core client classes exposed by the consumer and producer and
>> it is the approach taken by projects that have a good track record with
>> regards to maintaining compatibility for long periods of time. I didn't see
>> much discussion or reasoning along the lines above for the
>> ProducerRecord/ConsumerRecord change and hence my comment (even if it may
>> actually me a good change once all is considered).
>>
>> Ismael
>>
>> On Thu, Nov 24, 2016 at 7:56 PM, Michael Pearce <Mi...@ig.com>
>> wrote:
>>
>>> +1 it would be nice, and as is less restrive would not cause any issue.
>>>
>>> Saying that agree this is a fix build not a feature build.
>>>
>>> Sent using OWA for iPhone
>>> ________________________________________
>>> From: Rajini Sivaram <ra...@googlemail.com>
>>> Sent: Thursday, November 24, 2016 12:17:13 PM
>>> To: dev@kafka.apache.org
>>> Subject: Re: [DISCUSS] 0.10.1.1 Plan
>>>
>>> Hi Ismael,
>>>
>>> OK, I do agree with you. At the moment, our code wraps these three
>> classes
>>> since they can't be extended. I recently noticed that two of the three
>> are
>>> now non-final in trunk. If all three were made non-final, we would like
>> to
>>> extend them,
>>>
>>> According to the Java specification:
>>>
>>> *Changing a class that is declared final to no longer be
>>> declared final does not break compatibility with pre-existing binaries.*
>>>
>>>
>>> So it shouldn't break anything. Perhaps that is the reason why KAFKA-4250
>>> was merged (I hadn't even noticed it). It is not critical, so I am ok
>> with
>>> it not being in the patch release.
>>>
>>>
>>> On Thu, Nov 24, 2016 at 11:43 AM, Ismael Juma <is...@gmail.com> wrote:
>>>
>>>> Hi Rajini,
>>>>
>>>> I think we should avoid making changes like that in patch releases as
>> it
>>>> means that code that compiles with 0.10.1.1 may not compile with
>>> 0.10.1.0.
>>>> Since we now have frequent time based releases, I think it makes sense
>>> for
>>>> patch releases to only include bug fixes and test stability fixes.
>>>>
>>>> About the specific changes that you mention, I didn't see a discussion
>>>> about compatibility guarantees that are expected by people who subclass
>>>> these classes so I think it was a bit premature to merge the
>>> ProducerRecord
>>>> and ConsumerRecord final removal change.
>>>>
>>>> Ismael
>>>>
>>>> On 24 Nov 2016 10:26 am, "Rajini Sivaram" <
>> rajinisivaram@googlemail.com>
>>>> wrote:
>>>>
>>>>> Can we add KAFKA-4440 and KAFKA-4250 to the the list? They make
>>>>> ProducerRecord/ConsumerRecord/RecordMetadata non-final so that they
>>> can
>>>> be
>>>>> extended. The changes have minimal impact on the codebase, but will
>>>> really
>>>>> help when implementing other producers/consumers. It is not a
>> bug-fix,
>>>> but
>>>>> if we are going to make the change, it will be good to have it in a
>>>> release
>>>>> soon.
>>>>>
>>>>> Thank you,
>>>>>
>>>>> Rajini
>>>>>
>>>>>
>>>>> On Thu, Nov 24, 2016 at 4:36 AM, Bernard Leach <
>>> leachbj@bouncycastle.org
>>>>>
>>>>> wrote:
>>>>>
>>>>>> Hi Guozhang,
>>>>>>
>>>>>> I have added KAFKA-4438 to that list as that would enable
>> publishing
>>>> the
>>>>>> scala 2.12 builds of 0.10.1.1. There are other tasks in order to
>>>>> actually
>>>>>> publish a 2.12 but merging that change would enable that process.
>>>>> There’s
>>>>>> a corresponding PR on github that consists of a cherry-pick of the
>>>>>> corresponding change from trunk.
>>>>>>
>>>>>> cheers,
>>>>>> bern
>>>>>>
>>>>>>> On 24 Nov 2016, at 06:58, Guozhang Wang <wa...@gmail.com>
>>> wrote:
>>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> We have resolved 15 JIRAs including a few critical bugs in the
>>> 0.10.1
>>>>>>> branch since 0.10.1.0 was released so I'd like to propose to
>>> release
>>>>>>> 0.10.1.1 soon:
>>>>>>>
>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%
>>>>>> 3D%20KAFKA%20AND%20resolution%20%3D%20Fixed%20AND%
>>>>>> 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
>>>>>> 20DESC%2C%20key%20DESC
>>>>>>>
>>>>>>> There are still a few outstanding issues that are not unresolved
>>> and
>>>>> have
>>>>>>> 0.10.1.1 as the target version:
>>>>>>>
>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%
>>>>>> 3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%
>>>>>> 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
>>>>>> 20DESC%2C%20key%20DESC
>>>>>>>
>>>>>>> Once we have resolved these issues I will start the release
>>> process.
>>>>>>>
>>>>>>> --
>>>>>>> -- Guozhang
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>>
>>>>> Rajini
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>> Rajini
>>> The information contained in this email is strictly confidential and for
>>> the use of the addressee only, unless otherwise indicated. If you are not
>>> the intended recipient, please do not read, copy, use or disclose to
>> others
>>> this message or any attachment. Please also notify the sender by replying
>>> to this email or by telephone (+44(020 7896 0011) and then delete the
>>> email and any copies of it. Opinions, conclusion (etc) that do not relate
>>> to the official business of this company shall be understood as neither
>>> given nor endorsed by it. IG is a trading name of IG Markets Limited (a
>>> company registered in England and Wales, company number 04008957) and IG
>>> Index Limited (a company registered in England and Wales, company number
>>> 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill,
>>> London EC4R 2YA. Both IG Markets Limited (register number 195355) and IG
>>> Index Limited (register number 114059) are authorised and regulated by
>> the
>>> Financial Conduct Authority.
>>>
>> The information contained in this email is strictly confidential and for
>> the use of the addressee only, unless otherwise indicated. If you are not
>> the intended recipient, please do not read, copy, use or disclose to others
>> this message or any attachment. Please also notify the sender by replying
>> to this email or by telephone (+44(020 7896 0011) and then delete the email
>> and any copies of it. Opinions, conclusion (etc) that do not relate to the
>> official business of this company shall be understood as neither given nor
>> endorsed by it. IG is a trading name of IG Markets Limited (a company
>> registered in England and Wales, company number 04008957) and IG Index
>> Limited (a company registered in England and Wales, company number
>> 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill,
>> London EC4R 2YA. Both IG Markets Limited (register number 195355) and IG
>> Index Limited (register number 114059) are authorised and regulated by the
>> Financial Conduct Authority.
>>
Re: [DISCUSS] 0.10.1.1 Plan
Posted by radai <ra...@gmail.com>.
"compatibility guarantees that are expected by people who subclass these
classes"
sorry if this is not the best thread for this discussion, but I just wanted
to pop in and say that since any subclassing of these will obviously not be
done within the kafka codebase - what guarantees are needed?
On Fri, Nov 25, 2016 at 11:13 PM, Michael Pearce <Mi...@ig.com>
wrote:
> As agreed that this should be purely a bug fix release for stability.
>
>
> I'd like to flag then we shouldn't be adding / merging in any Jira's that
> are not bugs.
>
> e.g. KAFKA-4438
>
>
> ________________________________________
> From: ismaelj@gmail.com <is...@gmail.com> on behalf of Ismael Juma <
> ismael@juma.me.uk>
> Sent: Friday, November 25, 2016 11:43 AM
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] 0.10.1.1 Plan
>
> Good, seems like we are in agreement about sticking to bug fixes for
> 0.10.1.1.
>
> Regarding the removal of final, I understand that it doesn't break
> backwards binary compatibility (it does break forwards compatibility and
> hence why it's more suited for feature releases; these are the same rules
> followed by the JDK and Scala).
>
> It's probably best to discuss this in another thread, but to clarify: the
> point I was making is that once you make a class non final, maintaining
> compatibility becomes more complex. You have to take into account that
> methods could have been overridden, for example. As such, some thought
> should be given to the scenarios under which classes can be extended, how
> we will ensure that we can evolve the class without breaking users, whether
> we want to make some methods final, whether we should add some
> documentation guiding users regarding good/bad examples of inheritance
> versus composition for these classes and so on. This is particularly
> important for core client classes exposed by the consumer and producer and
> it is the approach taken by projects that have a good track record with
> regards to maintaining compatibility for long periods of time. I didn't see
> much discussion or reasoning along the lines above for the
> ProducerRecord/ConsumerRecord change and hence my comment (even if it may
> actually me a good change once all is considered).
>
> Ismael
>
> On Thu, Nov 24, 2016 at 7:56 PM, Michael Pearce <Mi...@ig.com>
> wrote:
>
> > +1 it would be nice, and as is less restrive would not cause any issue.
> >
> > Saying that agree this is a fix build not a feature build.
> >
> > Sent using OWA for iPhone
> > ________________________________________
> > From: Rajini Sivaram <ra...@googlemail.com>
> > Sent: Thursday, November 24, 2016 12:17:13 PM
> > To: dev@kafka.apache.org
> > Subject: Re: [DISCUSS] 0.10.1.1 Plan
> >
> > Hi Ismael,
> >
> > OK, I do agree with you. At the moment, our code wraps these three
> classes
> > since they can't be extended. I recently noticed that two of the three
> are
> > now non-final in trunk. If all three were made non-final, we would like
> to
> > extend them,
> >
> > According to the Java specification:
> >
> > *Changing a class that is declared final to no longer be
> > declared final does not break compatibility with pre-existing binaries.*
> >
> >
> > So it shouldn't break anything. Perhaps that is the reason why KAFKA-4250
> > was merged (I hadn't even noticed it). It is not critical, so I am ok
> with
> > it not being in the patch release.
> >
> >
> > On Thu, Nov 24, 2016 at 11:43 AM, Ismael Juma <is...@gmail.com> wrote:
> >
> > > Hi Rajini,
> > >
> > > I think we should avoid making changes like that in patch releases as
> it
> > > means that code that compiles with 0.10.1.1 may not compile with
> > 0.10.1.0.
> > > Since we now have frequent time based releases, I think it makes sense
> > for
> > > patch releases to only include bug fixes and test stability fixes.
> > >
> > > About the specific changes that you mention, I didn't see a discussion
> > > about compatibility guarantees that are expected by people who subclass
> > > these classes so I think it was a bit premature to merge the
> > ProducerRecord
> > > and ConsumerRecord final removal change.
> > >
> > > Ismael
> > >
> > > On 24 Nov 2016 10:26 am, "Rajini Sivaram" <
> rajinisivaram@googlemail.com>
> > > wrote:
> > >
> > > > Can we add KAFKA-4440 and KAFKA-4250 to the the list? They make
> > > > ProducerRecord/ConsumerRecord/RecordMetadata non-final so that they
> > can
> > > be
> > > > extended. The changes have minimal impact on the codebase, but will
> > > really
> > > > help when implementing other producers/consumers. It is not a
> bug-fix,
> > > but
> > > > if we are going to make the change, it will be good to have it in a
> > > release
> > > > soon.
> > > >
> > > > Thank you,
> > > >
> > > > Rajini
> > > >
> > > >
> > > > On Thu, Nov 24, 2016 at 4:36 AM, Bernard Leach <
> > leachbj@bouncycastle.org
> > > >
> > > > wrote:
> > > >
> > > > > Hi Guozhang,
> > > > >
> > > > > I have added KAFKA-4438 to that list as that would enable
> publishing
> > > the
> > > > > scala 2.12 builds of 0.10.1.1. There are other tasks in order to
> > > > actually
> > > > > publish a 2.12 but merging that change would enable that process.
> > > > There’s
> > > > > a corresponding PR on github that consists of a cherry-pick of the
> > > > > corresponding change from trunk.
> > > > >
> > > > > cheers,
> > > > > bern
> > > > >
> > > > > > On 24 Nov 2016, at 06:58, Guozhang Wang <wa...@gmail.com>
> > wrote:
> > > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > We have resolved 15 JIRAs including a few critical bugs in the
> > 0.10.1
> > > > > > branch since 0.10.1.0 was released so I'd like to propose to
> > release
> > > > > > 0.10.1.1 soon:
> > > > > >
> > > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > > > 3D%20KAFKA%20AND%20resolution%20%3D%20Fixed%20AND%
> > > > > 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> > > > > 20DESC%2C%20key%20DESC
> > > > > >
> > > > > > There are still a few outstanding issues that are not unresolved
> > and
> > > > have
> > > > > > 0.10.1.1 as the target version:
> > > > > >
> > > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > > > 3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%
> > > > > 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> > > > > 20DESC%2C%20key%20DESC
> > > > > >
> > > > > > Once we have resolved these issues I will start the release
> > process.
> > > > > >
> > > > > > --
> > > > > > -- Guozhang
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > >
> > > > Rajini
> > > >
> > >
> >
> >
> >
> > --
> > Regards,
> >
> > Rajini
> > The information contained in this email is strictly confidential and for
> > the use of the addressee only, unless otherwise indicated. If you are not
> > the intended recipient, please do not read, copy, use or disclose to
> others
> > this message or any attachment. Please also notify the sender by replying
> > to this email or by telephone (+44(020 7896 0011) and then delete the
> > email and any copies of it. Opinions, conclusion (etc) that do not relate
> > to the official business of this company shall be understood as neither
> > given nor endorsed by it. IG is a trading name of IG Markets Limited (a
> > company registered in England and Wales, company number 04008957) and IG
> > Index Limited (a company registered in England and Wales, company number
> > 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill,
> > London EC4R 2YA. Both IG Markets Limited (register number 195355) and IG
> > Index Limited (register number 114059) are authorised and regulated by
> the
> > Financial Conduct Authority.
> >
> The information contained in this email is strictly confidential and for
> the use of the addressee only, unless otherwise indicated. If you are not
> the intended recipient, please do not read, copy, use or disclose to others
> this message or any attachment. Please also notify the sender by replying
> to this email or by telephone (+44(020 7896 0011) and then delete the email
> and any copies of it. Opinions, conclusion (etc) that do not relate to the
> official business of this company shall be understood as neither given nor
> endorsed by it. IG is a trading name of IG Markets Limited (a company
> registered in England and Wales, company number 04008957) and IG Index
> Limited (a company registered in England and Wales, company number
> 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill,
> London EC4R 2YA. Both IG Markets Limited (register number 195355) and IG
> Index Limited (register number 114059) are authorised and regulated by the
> Financial Conduct Authority.
>
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Michael Pearce <Mi...@ig.com>.
As agreed that this should be purely a bug fix release for stability.
I'd like to flag then we shouldn't be adding / merging in any Jira's that are not bugs.
e.g. KAFKA-4438
________________________________________
From: ismaelj@gmail.com <is...@gmail.com> on behalf of Ismael Juma <is...@juma.me.uk>
Sent: Friday, November 25, 2016 11:43 AM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] 0.10.1.1 Plan
Good, seems like we are in agreement about sticking to bug fixes for
0.10.1.1.
Regarding the removal of final, I understand that it doesn't break
backwards binary compatibility (it does break forwards compatibility and
hence why it's more suited for feature releases; these are the same rules
followed by the JDK and Scala).
It's probably best to discuss this in another thread, but to clarify: the
point I was making is that once you make a class non final, maintaining
compatibility becomes more complex. You have to take into account that
methods could have been overridden, for example. As such, some thought
should be given to the scenarios under which classes can be extended, how
we will ensure that we can evolve the class without breaking users, whether
we want to make some methods final, whether we should add some
documentation guiding users regarding good/bad examples of inheritance
versus composition for these classes and so on. This is particularly
important for core client classes exposed by the consumer and producer and
it is the approach taken by projects that have a good track record with
regards to maintaining compatibility for long periods of time. I didn't see
much discussion or reasoning along the lines above for the
ProducerRecord/ConsumerRecord change and hence my comment (even if it may
actually me a good change once all is considered).
Ismael
On Thu, Nov 24, 2016 at 7:56 PM, Michael Pearce <Mi...@ig.com>
wrote:
> +1 it would be nice, and as is less restrive would not cause any issue.
>
> Saying that agree this is a fix build not a feature build.
>
> Sent using OWA for iPhone
> ________________________________________
> From: Rajini Sivaram <ra...@googlemail.com>
> Sent: Thursday, November 24, 2016 12:17:13 PM
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] 0.10.1.1 Plan
>
> Hi Ismael,
>
> OK, I do agree with you. At the moment, our code wraps these three classes
> since they can't be extended. I recently noticed that two of the three are
> now non-final in trunk. If all three were made non-final, we would like to
> extend them,
>
> According to the Java specification:
>
> *Changing a class that is declared final to no longer be
> declared final does not break compatibility with pre-existing binaries.*
>
>
> So it shouldn't break anything. Perhaps that is the reason why KAFKA-4250
> was merged (I hadn't even noticed it). It is not critical, so I am ok with
> it not being in the patch release.
>
>
> On Thu, Nov 24, 2016 at 11:43 AM, Ismael Juma <is...@gmail.com> wrote:
>
> > Hi Rajini,
> >
> > I think we should avoid making changes like that in patch releases as it
> > means that code that compiles with 0.10.1.1 may not compile with
> 0.10.1.0.
> > Since we now have frequent time based releases, I think it makes sense
> for
> > patch releases to only include bug fixes and test stability fixes.
> >
> > About the specific changes that you mention, I didn't see a discussion
> > about compatibility guarantees that are expected by people who subclass
> > these classes so I think it was a bit premature to merge the
> ProducerRecord
> > and ConsumerRecord final removal change.
> >
> > Ismael
> >
> > On 24 Nov 2016 10:26 am, "Rajini Sivaram" <ra...@googlemail.com>
> > wrote:
> >
> > > Can we add KAFKA-4440 and KAFKA-4250 to the the list? They make
> > > ProducerRecord/ConsumerRecord/RecordMetadata non-final so that they
> can
> > be
> > > extended. The changes have minimal impact on the codebase, but will
> > really
> > > help when implementing other producers/consumers. It is not a bug-fix,
> > but
> > > if we are going to make the change, it will be good to have it in a
> > release
> > > soon.
> > >
> > > Thank you,
> > >
> > > Rajini
> > >
> > >
> > > On Thu, Nov 24, 2016 at 4:36 AM, Bernard Leach <
> leachbj@bouncycastle.org
> > >
> > > wrote:
> > >
> > > > Hi Guozhang,
> > > >
> > > > I have added KAFKA-4438 to that list as that would enable publishing
> > the
> > > > scala 2.12 builds of 0.10.1.1. There are other tasks in order to
> > > actually
> > > > publish a 2.12 but merging that change would enable that process.
> > > There’s
> > > > a corresponding PR on github that consists of a cherry-pick of the
> > > > corresponding change from trunk.
> > > >
> > > > cheers,
> > > > bern
> > > >
> > > > > On 24 Nov 2016, at 06:58, Guozhang Wang <wa...@gmail.com>
> wrote:
> > > > >
> > > > > Hi everyone,
> > > > >
> > > > > We have resolved 15 JIRAs including a few critical bugs in the
> 0.10.1
> > > > > branch since 0.10.1.0 was released so I'd like to propose to
> release
> > > > > 0.10.1.1 soon:
> > > > >
> > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > > 3D%20KAFKA%20AND%20resolution%20%3D%20Fixed%20AND%
> > > > 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> > > > 20DESC%2C%20key%20DESC
> > > > >
> > > > > There are still a few outstanding issues that are not unresolved
> and
> > > have
> > > > > 0.10.1.1 as the target version:
> > > > >
> > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > > 3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%
> > > > 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> > > > 20DESC%2C%20key%20DESC
> > > > >
> > > > > Once we have resolved these issues I will start the release
> process.
> > > > >
> > > > > --
> > > > > -- Guozhang
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > >
> > > Rajini
> > >
> >
>
>
>
> --
> Regards,
>
> Rajini
> The information contained in this email is strictly confidential and for
> the use of the addressee only, unless otherwise indicated. If you are not
> the intended recipient, please do not read, copy, use or disclose to others
> this message or any attachment. Please also notify the sender by replying
> to this email or by telephone (+44(020 7896 0011) and then delete the
> email and any copies of it. Opinions, conclusion (etc) that do not relate
> to the official business of this company shall be understood as neither
> given nor endorsed by it. IG is a trading name of IG Markets Limited (a
> company registered in England and Wales, company number 04008957) and IG
> Index Limited (a company registered in England and Wales, company number
> 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill,
> London EC4R 2YA. Both IG Markets Limited (register number 195355) and IG
> Index Limited (register number 114059) are authorised and regulated by the
> Financial Conduct Authority.
>
The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44(020 7896 0011) and then delete the email and any copies of it. Opinions, conclusion (etc) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG is a trading name of IG Markets Limited (a company registered in England and Wales, company number 04008957) and IG Index Limited (a company registered in England and Wales, company number 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill, London EC4R 2YA. Both IG Markets Limited (register number 195355) and IG Index Limited (register number 114059) are authorised and regulated by the Financial Conduct Authority.
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Ismael Juma <is...@juma.me.uk>.
Good, seems like we are in agreement about sticking to bug fixes for
0.10.1.1.
Regarding the removal of final, I understand that it doesn't break
backwards binary compatibility (it does break forwards compatibility and
hence why it's more suited for feature releases; these are the same rules
followed by the JDK and Scala).
It's probably best to discuss this in another thread, but to clarify: the
point I was making is that once you make a class non final, maintaining
compatibility becomes more complex. You have to take into account that
methods could have been overridden, for example. As such, some thought
should be given to the scenarios under which classes can be extended, how
we will ensure that we can evolve the class without breaking users, whether
we want to make some methods final, whether we should add some
documentation guiding users regarding good/bad examples of inheritance
versus composition for these classes and so on. This is particularly
important for core client classes exposed by the consumer and producer and
it is the approach taken by projects that have a good track record with
regards to maintaining compatibility for long periods of time. I didn't see
much discussion or reasoning along the lines above for the
ProducerRecord/ConsumerRecord change and hence my comment (even if it may
actually me a good change once all is considered).
Ismael
On Thu, Nov 24, 2016 at 7:56 PM, Michael Pearce <Mi...@ig.com>
wrote:
> +1 it would be nice, and as is less restrive would not cause any issue.
>
> Saying that agree this is a fix build not a feature build.
>
> Sent using OWA for iPhone
> ________________________________________
> From: Rajini Sivaram <ra...@googlemail.com>
> Sent: Thursday, November 24, 2016 12:17:13 PM
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] 0.10.1.1 Plan
>
> Hi Ismael,
>
> OK, I do agree with you. At the moment, our code wraps these three classes
> since they can't be extended. I recently noticed that two of the three are
> now non-final in trunk. If all three were made non-final, we would like to
> extend them,
>
> According to the Java specification:
>
> *Changing a class that is declared final to no longer be
> declared final does not break compatibility with pre-existing binaries.*
>
>
> So it shouldn't break anything. Perhaps that is the reason why KAFKA-4250
> was merged (I hadn't even noticed it). It is not critical, so I am ok with
> it not being in the patch release.
>
>
> On Thu, Nov 24, 2016 at 11:43 AM, Ismael Juma <is...@gmail.com> wrote:
>
> > Hi Rajini,
> >
> > I think we should avoid making changes like that in patch releases as it
> > means that code that compiles with 0.10.1.1 may not compile with
> 0.10.1.0.
> > Since we now have frequent time based releases, I think it makes sense
> for
> > patch releases to only include bug fixes and test stability fixes.
> >
> > About the specific changes that you mention, I didn't see a discussion
> > about compatibility guarantees that are expected by people who subclass
> > these classes so I think it was a bit premature to merge the
> ProducerRecord
> > and ConsumerRecord final removal change.
> >
> > Ismael
> >
> > On 24 Nov 2016 10:26 am, "Rajini Sivaram" <ra...@googlemail.com>
> > wrote:
> >
> > > Can we add KAFKA-4440 and KAFKA-4250 to the the list? They make
> > > ProducerRecord/ConsumerRecord/RecordMetadata non-final so that they
> can
> > be
> > > extended. The changes have minimal impact on the codebase, but will
> > really
> > > help when implementing other producers/consumers. It is not a bug-fix,
> > but
> > > if we are going to make the change, it will be good to have it in a
> > release
> > > soon.
> > >
> > > Thank you,
> > >
> > > Rajini
> > >
> > >
> > > On Thu, Nov 24, 2016 at 4:36 AM, Bernard Leach <
> leachbj@bouncycastle.org
> > >
> > > wrote:
> > >
> > > > Hi Guozhang,
> > > >
> > > > I have added KAFKA-4438 to that list as that would enable publishing
> > the
> > > > scala 2.12 builds of 0.10.1.1. There are other tasks in order to
> > > actually
> > > > publish a 2.12 but merging that change would enable that process.
> > > There’s
> > > > a corresponding PR on github that consists of a cherry-pick of the
> > > > corresponding change from trunk.
> > > >
> > > > cheers,
> > > > bern
> > > >
> > > > > On 24 Nov 2016, at 06:58, Guozhang Wang <wa...@gmail.com>
> wrote:
> > > > >
> > > > > Hi everyone,
> > > > >
> > > > > We have resolved 15 JIRAs including a few critical bugs in the
> 0.10.1
> > > > > branch since 0.10.1.0 was released so I'd like to propose to
> release
> > > > > 0.10.1.1 soon:
> > > > >
> > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > > 3D%20KAFKA%20AND%20resolution%20%3D%20Fixed%20AND%
> > > > 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> > > > 20DESC%2C%20key%20DESC
> > > > >
> > > > > There are still a few outstanding issues that are not unresolved
> and
> > > have
> > > > > 0.10.1.1 as the target version:
> > > > >
> > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > > 3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%
> > > > 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> > > > 20DESC%2C%20key%20DESC
> > > > >
> > > > > Once we have resolved these issues I will start the release
> process.
> > > > >
> > > > > --
> > > > > -- Guozhang
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > >
> > > Rajini
> > >
> >
>
>
>
> --
> Regards,
>
> Rajini
> The information contained in this email is strictly confidential and for
> the use of the addressee only, unless otherwise indicated. If you are not
> the intended recipient, please do not read, copy, use or disclose to others
> this message or any attachment. Please also notify the sender by replying
> to this email or by telephone (+44(020 7896 0011) and then delete the
> email and any copies of it. Opinions, conclusion (etc) that do not relate
> to the official business of this company shall be understood as neither
> given nor endorsed by it. IG is a trading name of IG Markets Limited (a
> company registered in England and Wales, company number 04008957) and IG
> Index Limited (a company registered in England and Wales, company number
> 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill,
> London EC4R 2YA. Both IG Markets Limited (register number 195355) and IG
> Index Limited (register number 114059) are authorised and regulated by the
> Financial Conduct Authority.
>
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Michael Pearce <Mi...@ig.com>.
+1 it would be nice, and as is less restrive would not cause any issue.
Saying that agree this is a fix build not a feature build.
Sent using OWA for iPhone
________________________________________
From: Rajini Sivaram <ra...@googlemail.com>
Sent: Thursday, November 24, 2016 12:17:13 PM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] 0.10.1.1 Plan
Hi Ismael,
OK, I do agree with you. At the moment, our code wraps these three classes
since they can't be extended. I recently noticed that two of the three are
now non-final in trunk. If all three were made non-final, we would like to
extend them,
According to the Java specification:
*Changing a class that is declared final to no longer be
declared final does not break compatibility with pre-existing binaries.*
So it shouldn't break anything. Perhaps that is the reason why KAFKA-4250
was merged (I hadn't even noticed it). It is not critical, so I am ok with
it not being in the patch release.
On Thu, Nov 24, 2016 at 11:43 AM, Ismael Juma <is...@gmail.com> wrote:
> Hi Rajini,
>
> I think we should avoid making changes like that in patch releases as it
> means that code that compiles with 0.10.1.1 may not compile with 0.10.1.0.
> Since we now have frequent time based releases, I think it makes sense for
> patch releases to only include bug fixes and test stability fixes.
>
> About the specific changes that you mention, I didn't see a discussion
> about compatibility guarantees that are expected by people who subclass
> these classes so I think it was a bit premature to merge the ProducerRecord
> and ConsumerRecord final removal change.
>
> Ismael
>
> On 24 Nov 2016 10:26 am, "Rajini Sivaram" <ra...@googlemail.com>
> wrote:
>
> > Can we add KAFKA-4440 and KAFKA-4250 to the the list? They make
> > ProducerRecord/ConsumerRecord/RecordMetadata non-final so that they can
> be
> > extended. The changes have minimal impact on the codebase, but will
> really
> > help when implementing other producers/consumers. It is not a bug-fix,
> but
> > if we are going to make the change, it will be good to have it in a
> release
> > soon.
> >
> > Thank you,
> >
> > Rajini
> >
> >
> > On Thu, Nov 24, 2016 at 4:36 AM, Bernard Leach <leachbj@bouncycastle.org
> >
> > wrote:
> >
> > > Hi Guozhang,
> > >
> > > I have added KAFKA-4438 to that list as that would enable publishing
> the
> > > scala 2.12 builds of 0.10.1.1. There are other tasks in order to
> > actually
> > > publish a 2.12 but merging that change would enable that process.
> > There’s
> > > a corresponding PR on github that consists of a cherry-pick of the
> > > corresponding change from trunk.
> > >
> > > cheers,
> > > bern
> > >
> > > > On 24 Nov 2016, at 06:58, Guozhang Wang <wa...@gmail.com> wrote:
> > > >
> > > > Hi everyone,
> > > >
> > > > We have resolved 15 JIRAs including a few critical bugs in the 0.10.1
> > > > branch since 0.10.1.0 was released so I'd like to propose to release
> > > > 0.10.1.1 soon:
> > > >
> > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > 3D%20KAFKA%20AND%20resolution%20%3D%20Fixed%20AND%
> > > 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> > > 20DESC%2C%20key%20DESC
> > > >
> > > > There are still a few outstanding issues that are not unresolved and
> > have
> > > > 0.10.1.1 as the target version:
> > > >
> > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > 3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%
> > > 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> > > 20DESC%2C%20key%20DESC
> > > >
> > > > Once we have resolved these issues I will start the release process.
> > > >
> > > > --
> > > > -- Guozhang
> > >
> > >
> >
> >
> > --
> > Regards,
> >
> > Rajini
> >
>
--
Regards,
Rajini
The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44(020 7896 0011) and then delete the email and any copies of it. Opinions, conclusion (etc) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG is a trading name of IG Markets Limited (a company registered in England and Wales, company number 04008957) and IG Index Limited (a company registered in England and Wales, company number 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill, London EC4R 2YA. Both IG Markets Limited (register number 195355) and IG Index Limited (register number 114059) are authorised and regulated by the Financial Conduct Authority.
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Rajini Sivaram <ra...@googlemail.com>.
Hi Ismael,
OK, I do agree with you. At the moment, our code wraps these three classes
since they can't be extended. I recently noticed that two of the three are
now non-final in trunk. If all three were made non-final, we would like to
extend them,
According to the Java specification:
*Changing a class that is declared final to no longer be
declared final does not break compatibility with pre-existing binaries.*
So it shouldn't break anything. Perhaps that is the reason why KAFKA-4250
was merged (I hadn't even noticed it). It is not critical, so I am ok with
it not being in the patch release.
On Thu, Nov 24, 2016 at 11:43 AM, Ismael Juma <is...@gmail.com> wrote:
> Hi Rajini,
>
> I think we should avoid making changes like that in patch releases as it
> means that code that compiles with 0.10.1.1 may not compile with 0.10.1.0.
> Since we now have frequent time based releases, I think it makes sense for
> patch releases to only include bug fixes and test stability fixes.
>
> About the specific changes that you mention, I didn't see a discussion
> about compatibility guarantees that are expected by people who subclass
> these classes so I think it was a bit premature to merge the ProducerRecord
> and ConsumerRecord final removal change.
>
> Ismael
>
> On 24 Nov 2016 10:26 am, "Rajini Sivaram" <ra...@googlemail.com>
> wrote:
>
> > Can we add KAFKA-4440 and KAFKA-4250 to the the list? They make
> > ProducerRecord/ConsumerRecord/RecordMetadata non-final so that they can
> be
> > extended. The changes have minimal impact on the codebase, but will
> really
> > help when implementing other producers/consumers. It is not a bug-fix,
> but
> > if we are going to make the change, it will be good to have it in a
> release
> > soon.
> >
> > Thank you,
> >
> > Rajini
> >
> >
> > On Thu, Nov 24, 2016 at 4:36 AM, Bernard Leach <leachbj@bouncycastle.org
> >
> > wrote:
> >
> > > Hi Guozhang,
> > >
> > > I have added KAFKA-4438 to that list as that would enable publishing
> the
> > > scala 2.12 builds of 0.10.1.1. There are other tasks in order to
> > actually
> > > publish a 2.12 but merging that change would enable that process.
> > There’s
> > > a corresponding PR on github that consists of a cherry-pick of the
> > > corresponding change from trunk.
> > >
> > > cheers,
> > > bern
> > >
> > > > On 24 Nov 2016, at 06:58, Guozhang Wang <wa...@gmail.com> wrote:
> > > >
> > > > Hi everyone,
> > > >
> > > > We have resolved 15 JIRAs including a few critical bugs in the 0.10.1
> > > > branch since 0.10.1.0 was released so I'd like to propose to release
> > > > 0.10.1.1 soon:
> > > >
> > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > 3D%20KAFKA%20AND%20resolution%20%3D%20Fixed%20AND%
> > > 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> > > 20DESC%2C%20key%20DESC
> > > >
> > > > There are still a few outstanding issues that are not unresolved and
> > have
> > > > 0.10.1.1 as the target version:
> > > >
> > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > 3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%
> > > 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> > > 20DESC%2C%20key%20DESC
> > > >
> > > > Once we have resolved these issues I will start the release process.
> > > >
> > > > --
> > > > -- Guozhang
> > >
> > >
> >
> >
> > --
> > Regards,
> >
> > Rajini
> >
>
--
Regards,
Rajini
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Ismael Juma <is...@gmail.com>.
Hi Rajini,
I think we should avoid making changes like that in patch releases as it
means that code that compiles with 0.10.1.1 may not compile with 0.10.1.0.
Since we now have frequent time based releases, I think it makes sense for
patch releases to only include bug fixes and test stability fixes.
About the specific changes that you mention, I didn't see a discussion
about compatibility guarantees that are expected by people who subclass
these classes so I think it was a bit premature to merge the ProducerRecord
and ConsumerRecord final removal change.
Ismael
On 24 Nov 2016 10:26 am, "Rajini Sivaram" <ra...@googlemail.com>
wrote:
> Can we add KAFKA-4440 and KAFKA-4250 to the the list? They make
> ProducerRecord/ConsumerRecord/RecordMetadata non-final so that they can be
> extended. The changes have minimal impact on the codebase, but will really
> help when implementing other producers/consumers. It is not a bug-fix, but
> if we are going to make the change, it will be good to have it in a release
> soon.
>
> Thank you,
>
> Rajini
>
>
> On Thu, Nov 24, 2016 at 4:36 AM, Bernard Leach <le...@bouncycastle.org>
> wrote:
>
> > Hi Guozhang,
> >
> > I have added KAFKA-4438 to that list as that would enable publishing the
> > scala 2.12 builds of 0.10.1.1. There are other tasks in order to
> actually
> > publish a 2.12 but merging that change would enable that process.
> There’s
> > a corresponding PR on github that consists of a cherry-pick of the
> > corresponding change from trunk.
> >
> > cheers,
> > bern
> >
> > > On 24 Nov 2016, at 06:58, Guozhang Wang <wa...@gmail.com> wrote:
> > >
> > > Hi everyone,
> > >
> > > We have resolved 15 JIRAs including a few critical bugs in the 0.10.1
> > > branch since 0.10.1.0 was released so I'd like to propose to release
> > > 0.10.1.1 soon:
> > >
> > > https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20KAFKA%20AND%20resolution%20%3D%20Fixed%20AND%
> > 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> > 20DESC%2C%20key%20DESC
> > >
> > > There are still a few outstanding issues that are not unresolved and
> have
> > > 0.10.1.1 as the target version:
> > >
> > > https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%
> > 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> > 20DESC%2C%20key%20DESC
> > >
> > > Once we have resolved these issues I will start the release process.
> > >
> > > --
> > > -- Guozhang
> >
> >
>
>
> --
> Regards,
>
> Rajini
>
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Rajini Sivaram <ra...@googlemail.com>.
Can we add KAFKA-4440 and KAFKA-4250 to the the list? They make
ProducerRecord/ConsumerRecord/RecordMetadata non-final so that they can be
extended. The changes have minimal impact on the codebase, but will really
help when implementing other producers/consumers. It is not a bug-fix, but
if we are going to make the change, it will be good to have it in a release
soon.
Thank you,
Rajini
On Thu, Nov 24, 2016 at 4:36 AM, Bernard Leach <le...@bouncycastle.org>
wrote:
> Hi Guozhang,
>
> I have added KAFKA-4438 to that list as that would enable publishing the
> scala 2.12 builds of 0.10.1.1. There are other tasks in order to actually
> publish a 2.12 but merging that change would enable that process. There’s
> a corresponding PR on github that consists of a cherry-pick of the
> corresponding change from trunk.
>
> cheers,
> bern
>
> > On 24 Nov 2016, at 06:58, Guozhang Wang <wa...@gmail.com> wrote:
> >
> > Hi everyone,
> >
> > We have resolved 15 JIRAs including a few critical bugs in the 0.10.1
> > branch since 0.10.1.0 was released so I'd like to propose to release
> > 0.10.1.1 soon:
> >
> > https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20KAFKA%20AND%20resolution%20%3D%20Fixed%20AND%
> 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> 20DESC%2C%20key%20DESC
> >
> > There are still a few outstanding issues that are not unresolved and have
> > 0.10.1.1 as the target version:
> >
> > https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%
> 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> 20DESC%2C%20key%20DESC
> >
> > Once we have resolved these issues I will start the release process.
> >
> > --
> > -- Guozhang
>
>
--
Regards,
Rajini
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Bernard Leach <le...@bouncycastle.org>.
Hi Guozhang,
I have added KAFKA-4438 to that list as that would enable publishing the scala 2.12 builds of 0.10.1.1. There are other tasks in order to actually publish a 2.12 but merging that change would enable that process. There’s a corresponding PR on github that consists of a cherry-pick of the corresponding change from trunk.
cheers,
bern
> On 24 Nov 2016, at 06:58, Guozhang Wang <wa...@gmail.com> wrote:
>
> Hi everyone,
>
> We have resolved 15 JIRAs including a few critical bugs in the 0.10.1
> branch since 0.10.1.0 was released so I'd like to propose to release
> 0.10.1.1 soon:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20KAFKA%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC
>
> There are still a few outstanding issues that are not unresolved and have
> 0.10.1.1 as the target version:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC
>
> Once we have resolved these issues I will start the release process.
>
> --
> -- Guozhang