@Bernard Leach That sounds good, we can consider adding a kafka_2.12-0.10.1.1-beta.tgz into maven for Scala community to test it out.
Guozhang On Tue, Nov 29, 2016 at 10:01 PM, Bernard Leach <leac...@bouncycastle.org> wrote: > Hi Guozhang, > > My suggestion was to not add kafka_2.12-0.10.1.0.tgz to downloads.html but > to still run the build to generate the maven artefacts for 2.12 and still > publish those to maven central. That would allow projects with binary > dependencies on kafka to obtain the required jars but hide away the tgz so > as not to imply that it is suitable for production use. Alternatively just > do the regular release process and mark it as beta on the downloads page. > Either way you’ll get more exposure and testing of the 2.12 version which > you won’t get via SNAPSHOTs from the trunk., > > cheers, > bern > > > On 30 Nov 2016, at 16:52, Guozhang Wang <wangg...@gmail.com> wrote: > > > > @Ignacio Solis > > > > The commit you mentioned was not intended for 0.10.1 but only for trunk > > (and there is a related KIP for this API change), but mistakenly gets > > leaked in and was already reverted. > > > > @Bernard Leach > > > > Could you elaborate on "instead simply publish the artifacts to maven > > central"? Currently the Kafka release is already through maven and we do > > not yet have kafka_2.12-0.10.1.0.tgz for binary. > > > > https://kafka.apache.org/downloads.html > > > > On Tue, Nov 29, 2016 at 5:40 PM, Gwen Shapira <g...@confluent.io> wrote: > > > >> Sorry for my misunderstanding, I assumed the request to include the > >> keyword removal came from you. > >> > >> And it is always good to know what versions LinkedIn are running, you > >> guys always serve as somewhat of a gold standard to the community :) > >> > >> 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 > >> > >> > >> > >> -- > >> Gwen Shapira > >> Product Manager | Confluent > >> 650.450.2760 | @gwenshap > >> Follow us: Twitter | blog > >> > > > > > > > > -- > > -- Guozhang > > -- -- Guozhang
