Hi Jay, Comments inline.
On Tue, Feb 23, 2016 at 10:38 AM, Jay Kreps <j...@confluent.io> wrote: > Would it make more sense to be able to announce both new clients stable and > deprecate both the scala clients at the same time (irrespective of whether > that is next release or one after)? I agree that there are benefits if we do it this way. However, I also think that there are benefits in giving advance warning if we have an alternative that is fully featured, production-ready and where we have given users some time to migrate (ie the 0.9.0.0 cycle). We did not wait for the new consumer to be ready before we added the new producer after all. The trade-offs are similar, in my opinion. Otherwise is an intermediate state > where we recommend you get off the scala producer but not the scala > consumer a bit awkward? I kind of think it is but don't have a strong > feeling either way so I'm +0. > We would be recommending you get off both, but we would only add the deprecation warning for the old producers for 0.10.0.0. I'd like us to be nice to our users and avoid spamming them with warnings without giving them a cycle to move to the new and recommended implementation. We could remove all the old clients at the same time, if we think that's better (ie the release after 0.10.0.0 at the earliest). Also what does deprecate mean? Does it mean we announce a schedule for > their removal or does it mean we will add the @deprecated annoyance markers > or both? > @deprecated markers for sure. With regards to the schedule for removal, I am not sure and I would like to hear opinions from people who are still using the old producers. Removing them is great for us from a maintainability perspective, but we also need to take into account how it will affect people who want to upgrade to the release where they are removed. I am not sure if we _need_ to commit to a particular release for removal. It may make sense to make that call after 0.10.0.0 goes out. It would be nice to avoid the MapReduce api conversion thing where the old > api is @deprecated but the new api has a bunch of gaps that render it > unusable for a year or so...that was kind of annoying. :-) > Yes, definitely. This is why I don't think we should deprecate the old consumers just yet. Ismael
