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 <g...@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 <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 >
