I understand that we cannot just break stuff (btw: also not for Streams!). But deprecating does not break anything, so I don't think it's a big deal to change the API as long as we keep the old API as deprecated.
-Matthias On 4/29/17 9:28 AM, Jay Kreps wrote: > Hey Matthias, > > Yeah I agree, I'm not against change as a general thing! I also think if > you look back on the last two years, we completely rewrote the producer and > consumer APIs, reworked the binary protocol many times over, and added the > connector and stream processing apis, both major new additions. So I don't > think we're in too much danger of stagnating! > > My two cents was just around breaking compatibility for trivial changes > like constructor => builder. I think this only applies to the producer, > consumer, and connect apis which are heavily embedded in hundreds of > ecosystem components that depend on them. This is different from direct > usage. If we break the streams api it is really no big deal---apps just > need to rebuild when they upgrade, not the end of the world at all. However > because many intermediate things depend on the Kafka producer you can cause > these weird situations where your app depends on two third party things > that use Kafka and each requires different, incompatible versions. We did > this a lot in earlier versions of Kafka and it was the cause of much angst > (and an ingrained general reluctance to upgrade) from our users. > > I still think we may have to break things, i just don't think we should do > it for things like builders vs direct constructors which i think are kind > of a debatable matter of taste. > > -Jay > > > > On Mon, Apr 24, 2017 at 9:40 AM, Matthias J. Sax <matth...@confluent.io> > wrote: > >> Hey Jay, >> >> I understand your concern, and for sure, we will need to keep the >> current constructors deprecated for a long time (ie, many years). >> >> But if we don't make the move, we will not be able to improve. And I >> think warnings about using deprecated APIs is an acceptable price to >> pay. And the API improvements will help new people who adopt Kafka to >> get started more easily. >> >> Otherwise Kafka might end up as many other enterprise software with a >> lots of old stuff that is kept forever because nobody has the guts to >> improve/change it. >> >> Of course, we can still improve the docs of the deprecated constructors, >> too. >> >> Just my two cents. >> >> >> -Matthias >> >> On 4/23/17 3:37 PM, Jay Kreps wrote: >>> Hey guys, >>> >>> I definitely think that the constructors could have been better designed, >>> but I think given that they're in heavy use I don't think this proposal >>> will improve things. Deprecating constructors just leaves everyone with >>> lots of warnings and crossed out things. We can't actually delete the >>> methods because lots of code needs to be usable across multiple Kafka >>> versions, right? So we aren't picking between the original approach >> (worse) >>> and the new approach (better); what we are proposing is a perpetual >>> mingling of the original style and the new style with a bunch of >> deprecated >>> stuff, which I think is worst of all. >>> >>> I'd vote for just documenting the meaning of null in the ProducerRecord >>> constructor. >>> >>> -Jay >>> >>> On Wed, Apr 19, 2017 at 3:34 PM, Stephane Maarek < >>> steph...@simplemachines.com.au> wrote: >>> >>>> Hi all, >>>> >>>> My first KIP, let me know your thoughts! >>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP+ >>>> 141+-+ProducerRecordBuilder+Interface >>>> >>>> >>>> Cheers, >>>> Stephane >>>> >>> >> >> >
signature.asc
Description: OpenPGP digital signature
