"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? On Fri, Nov 25, 2016 at 11:13 PM, Michael Pearce <michael.pea...@ig.com> wrote: > As agreed that this should be purely a bug fix release for stability. > > > I'd like to flag then we shouldn't be adding / merging in any Jira's that > are not bugs. > > e.g. KAFKA-4438 > > > ________________________________________ > From: isma...@gmail.com <isma...@gmail.com> on behalf of Ismael Juma < > ism...@juma.me.uk> > Sent: Friday, November 25, 2016 11:43 AM > To: dev@kafka.apache.org > Subject: Re: [DISCUSS] 0.10.1.1 Plan > > Good, seems like we are in agreement about sticking to bug fixes for > 0.10.1.1. > > Regarding the removal of final, I understand that it doesn't break > backwards binary compatibility (it does break forwards compatibility and > hence why it's more suited for feature releases; these are the same rules > followed by the JDK and Scala). > > It's probably best to discuss this in another thread, but to clarify: the > point I was making is that once you make a class non final, maintaining > compatibility becomes more complex. You have to take into account that > methods could have been overridden, for example. As such, some thought > should be given to the scenarios under which classes can be extended, how > we will ensure that we can evolve the class without breaking users, whether > we want to make some methods final, whether we should add some > documentation guiding users regarding good/bad examples of inheritance > versus composition for these classes and so on. This is particularly > important for core client classes exposed by the consumer and producer and > it is the approach taken by projects that have a good track record with > regards to maintaining compatibility for long periods of time. I didn't see > much discussion or reasoning along the lines above for the > ProducerRecord/ConsumerRecord change and hence my comment (even if it may > actually me a good change once all is considered). > > Ismael > > On Thu, Nov 24, 2016 at 7:56 PM, Michael Pearce <michael.pea...@ig.com> > wrote: > > > +1 it would be nice, and as is less restrive would not cause any issue. > > > > Saying that agree this is a fix build not a feature build. > > > > Sent using OWA for iPhone > > ________________________________________ > > From: Rajini Sivaram <rajinisiva...@googlemail.com> > > Sent: Thursday, November 24, 2016 12:17:13 PM > > To: dev@kafka.apache.org > > Subject: Re: [DISCUSS] 0.10.1.1 Plan > > > > Hi Ismael, > > > > OK, I do agree with you. At the moment, our code wraps these three > classes > > since they can't be extended. I recently noticed that two of the three > are > > now non-final in trunk. If all three were made non-final, we would like > to > > extend them, > > > > According to the Java specification: > > > > *Changing a class that is declared final to no longer be > > declared final does not break compatibility with pre-existing binaries.* > > > > > > So it shouldn't break anything. Perhaps that is the reason why KAFKA-4250 > > was merged (I hadn't even noticed it). It is not critical, so I am ok > with > > it not being in the patch release. > > > > > > On Thu, Nov 24, 2016 at 11:43 AM, Ismael Juma <isma...@gmail.com> wrote: > > > > > Hi Rajini, > > > > > > I think we should avoid making changes like that in patch releases as > it > > > means that code that compiles with 0.10.1.1 may not compile with > > 0.10.1.0. > > > Since we now have frequent time based releases, I think it makes sense > > for > > > patch releases to only include bug fixes and test stability fixes. > > > > > > About the specific changes that you mention, I didn't see a discussion > > > about compatibility guarantees that are expected by people who subclass > > > these classes so I think it was a bit premature to merge the > > ProducerRecord > > > and ConsumerRecord final removal change. > > > > > > Ismael > > > > > > On 24 Nov 2016 10:26 am, "Rajini Sivaram" < > rajinisiva...@googlemail.com> > > > wrote: > > > > > > > Can we add KAFKA-4440 and KAFKA-4250 to the the list? They make > > > > ProducerRecord/ConsumerRecord/RecordMetadata non-final so that they > > can > > > be > > > > extended. The changes have minimal impact on the codebase, but will > > > really > > > > help when implementing other producers/consumers. It is not a > bug-fix, > > > but > > > > if we are going to make the change, it will be good to have it in a > > > release > > > > soon. > > > > > > > > Thank you, > > > > > > > > Rajini > > > > > > > > > > > > On Thu, Nov 24, 2016 at 4:36 AM, Bernard Leach < > > leac...@bouncycastle.org > > > > > > > > wrote: > > > > > > > > > Hi Guozhang, > > > > > > > > > > I have added KAFKA-4438 to that list as that would enable > publishing > > > the > > > > > scala 2.12 builds of 0.10.1.1. There are other tasks in order to > > > > actually > > > > > publish a 2.12 but merging that change would enable that process. > > > > There’s > > > > > a corresponding PR on github that consists of a cherry-pick of the > > > > > corresponding change from trunk. > > > > > > > > > > cheers, > > > > > bern > > > > > > > > > > > On 24 Nov 2016, at 06:58, Guozhang Wang <wangg...@gmail.com> > > wrote: > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > We have resolved 15 JIRAs including a few critical bugs in the > > 0.10.1 > > > > > > branch since 0.10.1.0 was released so I'd like to propose to > > release > > > > > > 0.10.1.1 soon: > > > > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20% > > > > > 3D%20KAFKA%20AND%20resolution%20%3D%20Fixed%20AND% > > > > > 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority% > > > > > 20DESC%2C%20key%20DESC > > > > > > > > > > > > There are still a few outstanding issues that are not unresolved > > and > > > > have > > > > > > 0.10.1.1 as the target version: > > > > > > > > > > > > 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 > > > > > > > > > > > > Once we have resolved these issues I will start the release > > process. > > > > > > > > > > > > -- > > > > > > -- Guozhang > > > > > > > > > > > > > > > > > > > > > > -- > > > > Regards, > > > > > > > > Rajini > > > > > > > > > > > > > > > -- > > Regards, > > > > Rajini > > The information contained in this email is strictly confidential and for > > the use of the addressee only, unless otherwise indicated. If you are not > > the intended recipient, please do not read, copy, use or disclose to > others > > this message or any attachment. Please also notify the sender by replying > > to this email or by telephone (+44(020 7896 0011) and then delete the > > email and any copies of it. Opinions, conclusion (etc) that do not relate > > to the official business of this company shall be understood as neither > > given nor endorsed by it. IG is a trading name of IG Markets Limited (a > > company registered in England and Wales, company number 04008957) and IG > > Index Limited (a company registered in England and Wales, company number > > 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill, > > London EC4R 2YA. Both IG Markets Limited (register number 195355) and IG > > Index Limited (register number 114059) are authorised and regulated by > the > > Financial Conduct Authority. > > > The information contained in this email is strictly confidential and for > the use of the addressee only, unless otherwise indicated. If you are not > the intended recipient, please do not read, copy, use or disclose to others > this message or any attachment. Please also notify the sender by replying > to this email or by telephone (+44(020 7896 0011) and then delete the email > and any copies of it. Opinions, conclusion (etc) that do not relate to the > official business of this company shall be understood as neither given nor > endorsed by it. IG is a trading name of IG Markets Limited (a company > registered in England and Wales, company number 04008957) and IG Index > Limited (a company registered in England and Wales, company number > 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill, > London EC4R 2YA. Both IG Markets Limited (register number 195355) and IG > Index Limited (register number 114059) are authorised and regulated by the > Financial Conduct Authority. >
