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
