+1 That sounds excellent. On Wed, 23 Nov 2016 at 11:04 Till Rohrmann <trohrm...@apache.org> wrote:
> +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 > > >