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 <iso...@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 <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 > > > > > > -- > Nacho - Ignacio Solis - iso...@igso.net >
