@Radai I think Ismael's point is that people who coded their applications against 0.10.1.1 should be able to swipe in the 0.10.1.0 jar without breaking the code (in practice maybe it is more likely the reverse scenario, that people coded against 0.10.1.0 and trying to swipe in a newer 0.10.1.1).
@Bernard Leach I agree that having Scala 2.12 support as early as possible than next Feb can help the Scala community who's using Kafka. However, the downside is that it may increase our release cycles for this bug-fix release as we need to add more validation process to make sure that builds with Scala12 works perfectly, while we are trying to make 0.10.1.1 out asap. Guozhang On Sun, Nov 27, 2016 at 5:16 PM, Bernard Leach <leac...@bouncycastle.org> wrote: > I guess bugs are in the eye of the beholder; I’d really like to see > KAFKA-4438 addressed as a patch release - the bug being "I can’t currently > build any scala 2.12 projects with Kafka as a dependency". There’s a PR > ready to go for the branch that has already been accepted to trunk and this > Ismael has addressed the risk issue by making the 2.12 not part of the > default build. > > There are a number of downstream projects awaiting kafka scala 2.12 > binaries so they can publish their own so getting this addressed before > February would really help push along the availability of 2.12 compatible > libraries. > > cheers, > bern. > > > On 27 Nov 2016, at 10:08, 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? > > > > 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. > >> > > -- -- Guozhang
