Status Update: All tasks marked for 0.10.1.1 as been resolved, will start the release process right away.
Guozhang On Fri, Dec 2, 2016 at 1:01 PM, Guozhang Wang <wangg...@gmail.com> wrote: > @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 > -- -- Guozhang
