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 <iso...@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 <ism...@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" <iso...@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 <ism...@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.rosenbl...@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 <ism...@juma.me.uk> >>>> wrote: >>>>>> >>>>>>> On Sat, Nov 26, 2016 at 11:08 PM, radai < >>> radai.rosenbl...@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 - iso...@igso.net >>>> >>> >> >> >> >> -- >> Nacho - Ignacio Solis - iso...@igso.net >> > > >
signature.asc
Description: OpenPGP digital signature
