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