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
