@Ignacio Solis The commit you mentioned was not intended for 0.10.1 but only for trunk (and there is a related KIP for this API change), but mistakenly gets leaked in and was already reverted.
@Bernard Leach Could you elaborate on "instead simply publish the artifacts to maven central"? Currently the Kafka release is already through maven and we do not yet have kafka_2.12-0.10.1.0.tgz for binary. https://kafka.apache.org/downloads.html On Tue, Nov 29, 2016 at 5:40 PM, Gwen Shapira <g...@confluent.io> wrote: > Sorry for my misunderstanding, I assumed the request to include the > keyword removal came from you. > > And it is always good to know what versions LinkedIn are running, you > guys always serve as somewhat of a gold standard to the community :) > > On Tue, Nov 29, 2016 at 5:32 PM, Ignacio Solis <iso...@igso.net> wrote: > > 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 > > > > -- > Gwen Shapira > Product Manager | Confluent > 650.450.2760 | @gwenshap > Follow us: Twitter | blog > -- -- Guozhang
