+1
This should always be the norm, especially for user-facing code.
While we are at it, perhaps when someone deprecates functionality the new
alternative should also be replaced right away.
E.g. Checkpointed is deprecated but all state management tests are actually
using this alternative.
cheers
Paris
> On 23 Nov 2016, at 11:21, Kostas Kloudas <k.klou...@data-artisans.com> wrote:
>
> +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
>>>>
>>>
>
