IMO, both old producer and old consumer APIs should be marked as deprecated for 0.8.3 (since the new code will be in and we want to encourage the switch).
I'd like to see 0.9 released with just the new java clients. On Thu, Aug 13, 2015 at 6:47 AM, Ismael Juma <ism...@juma.me.uk> wrote: > On Thu, Aug 13, 2015 at 8:36 AM, Ewen Cheslack-Postava <e...@confluent.io> > wrote: > > > On deprecation, I think we should definitely use the standard annotation > to > > handle this. > > > Thanks Ewen. I agree that we should use @Deprecated for language-level > deprecations. My question was regarding the following: > > - unstable - can change at any time > > - evolving - can break compatibility at minor releases (i.e. 0.9 may be > > incompatible with 0.8) > > - stable - will only break compatibility at major releases (1.0, 2.0, > etc) > > > > > Let's pick `evolving`, as an example. Does it mean that we can break > compatibility at minor releases without a deprecation cycle? Or does it > mean that we would need to deprecate it for one minor release and then > remove in the next? The latter is nicer for users as they have one release > where both the deprecated and recommended still work, but it adds more > overhead to Kafka development. What is the current thinking around this? > > The annotation doesn't necessarily work for everything (e.g., > > deprecating older versions of the protocol doesn't work via Java > > deprecation annotations), but we should definitely use it for deprecated > > Java/Scala APIs. Perhaps we should start by marking all the old producer > > APIs deprecated > > > Seems sensible assuming that users have found it easy to migrate to the new > producer in the latest release. > > and, after the next release, the old consumer APIs too? :) > > > Similar to above, it would be good to do that once we have some reports > from users who moved from one API to the next. > > Best, > Ismael >
