Hey Ismael, Thanks for bringing this up again. Just a quick question: if we do #1, then there's no way that a user binary could work against both 0.9 and 0.10 of kafka-clients, right? I'm not sure if that is much of a problem, but may cause a little pain if a user somehow depends transitively on different versions. Excluding this change, would we otherwise expect kafka-clients-0.9 to work with an 0.10 broker? I thought the changes for KIP-32 continued to support the old message format, but I could be wrong.
-Jason On Mon, Mar 7, 2016 at 3:29 PM, Ismael Juma <ism...@juma.me.uk> wrote: > Coming back to this, see below. > > On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson <ja...@confluent.io> > wrote: > > > > > 1. For subscribe() and assign(), change the parameter type to collection > as > > planned in the KIP. This is at least source-compatible, so as long as > users > > compile against the updated release, there shouldn't be any problems. > > > > I think this one seems to be the least controversial part of the proposal. > And I agree with this suggestion. > > 2. Instead of changing the signatures of the current pause/resume/seek > > APIs, maybe we can overload them. This keeps compatibility and supports > the > > more convenient collection usage, but the cost is some API bloat. > > > > It seems like there is no clear winner, so I am OK with this too. > > Given the release plan for 0.10.0.0 that is being voted on, I think we > should make a decision on this one way or another very soon. > > Ismael >
