+1 and we should apply the same to all deprecated interfaces/abstract classes.
> On Nov 23, 2016, at 11:13 AM, Aljoscha Krettek <aljos...@apache.org> wrote:
>
> +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
>>>
>>
