Got it! I was under the impression that deprecated means "there is something better now and we'll remove this in few releases". But yeah, lets avoid marking it for now.
On Thu, Aug 13, 2015 at 4:58 PM, Neha Narkhede <n...@confluent.io> wrote: > Thanks for starting the discussion around API annotations, Gwen! I think it > is better to add the deprecated annotation after the new consumer API is > successfully deployed at a couple places. > > On Thu, Aug 13, 2015 at 3:42 PM, Ismael Juma <ism...@juma.me.uk> wrote: > > > 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 > > > > > > -- > Thanks, > Neha >
