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 <ism...@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 <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 >> -- Gwen Shapira Product Manager | Confluent 650.450.2760 | @gwenshap Follow us: Twitter | blog
