I understand the convenience of pointing at a JIRA/PR, but can we put the concrete changes proposed in the JIRA (under "Proposed Changes"). I don't think voting on the KIP would be reasonable otherwise since the changes under vote could change arbitrarily...
I'm increasingly skeptical of adding more convenience constructors -- the current patch adds timestamps, we're about to add headers as well (for core, for Connect we have https://cwiki.apache.org/confluence/display/KAFKA/KIP-145+-+Expose+Record+Headers+in+Kafka+Connect in flight). It just continues to get messier over time. I think builders in the right context are useful, as long as they exceed a certain number of parameters (SchemaBuilder in Connect is an artifact of that position). I don't think a transition period with 2 ways to construct an object is actually a problem -- if there's always an "all N parameters" version of the constructor, all other constructors are just convenience shortcuts, but the Builder provides a shorthand. I also agree w/ Ismael that deprecating to aggressively is bad -- we added the APIs instead of a builder and there's not any real maintenance cost, so why add the deprecation? I don't want to suggest actually adding such an annotation, but the real issue here is that one API will become "preferred" for some time. -Ewen On Tue, May 2, 2017 at 1:15 AM, Ismael Juma <ism...@juma.me.uk> wrote: > Hi Matthias, > > Deprecating widely used APIs is a big deal. Build warnings are a nuisance > and can potentially break the build for those who have a zero-warnings > policy (which is good practice). It creates a bunch of busy work for our > users and various resources like books, blog posts, etc. become out of > date. > > This does not mean that we should not do it, but the benefit has to be > worth it and we should not do it lightly. > > Ismael > > On Sat, Apr 29, 2017 at 6:52 PM, Matthias J. Sax <matth...@confluent.io> > wrote: > > > 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 > > >>>> > > >>> > > >> > > >> > > > > > > > >
