On Thu, Aug 13, 2015 at 10:41 PM, Gwen Shapira <g...@confluent.io> wrote:
> 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 can see the appeal of this, but it's also worth considering the downsides for users too: * It will introduce a number of deprecation warnings to everyone that upgrades to 0.8.3 even though the old Consumer APIs still work fine (also worth keeping in mind that in many projects, warnings cause a build failure) * The new Consumer is still marked as `Unstable` so it seems a bit odd to deprecate the old one I think a more conservative option would be to update the documentation to encourage users to move to the new consumer without adding deprecation annotations to the old consumer APIs. Some features that are only available in the new consumer (e.g. SSL support) provide further incentive to move. As Ewen suggested, the old consumer would then be deprecated in the following release. And removed in the one after that. The main downside would be having to maintain the old consumer for a little while longer. Something to think about. :) Best, Ismael
