+1 for your proposal.
Cheers,
Till
On Wed, Nov 23, 2016 at 9:33 AM, Fabian Hueske <fhue...@gmail.com> wrote:
> I agree on this one.
> Whenever we deprecate a method or a feature we should add a comment that
> explains the new API or why the feature was removed without replacement.
>
> Enforcing this information through checkstyle makes sense as well, IMO.
>
> Cheers, Fabian
>
> 2016-11-23 4:42 GMT+01:00 sjk <shijinkui...@163.com>:
>
> > Hi, all
> >
> > Let’s have look at Checkpointed interface below. It declared deprecated
> > but have no detail for why, when and how replace this function. It’s a
> big
> > trouble for the users.
> >
> > @Deprecated
> > @PublicEvolving
> > public interface Checkpointed<T extends Serializable> extends
> > CheckpointedRestoring<T> {
> >
> >
> > I think we should have more detail: when give up, who replace it, why
> > deprecated.
> >
> > For Java code, add detail deprecated reason in code annotations.
> > For Scala code, replace Java annotation @Deprecated(,,) with Scala
> > annotation @deprecated, such as
> > @deprecated(message = "the reason", since = "when fully give up”)
> >
> > Add this rule to customized checkstyle plugin of maven and SBT.
> >
> > Best regard
> > -Jinkui Shi
>
