@Sean, There have been some discussions about KAFKA-4250, from Ismael. The main concern is on backward compatibility between 0.10.1.0 and the coming 0.10.1.1.
Status Update: We are having three tasks left for 0.10.1.1, all of which have a PR under review and close to be merged. After those three I will start the release process and start a separate thread on the RC voting. https://issues.apache.org/jira/issues/?jql=project%20%3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC Guozhang On Thu, Dec 1, 2016 at 4:40 PM, Sean McCauliff <sean.mccaul...@gmail.com> wrote: > Well I would like KAFKA-4250 (make ProducerRecord and ConsumerRecord > extensible) in the 0.10.1 branch if is not a big deal. They are just > dumb structs. But they are final so no extensibility is possible. > > Sean > > 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 > >> > -- -- Guozhang
