flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aljoscha Krettek <aljos...@apache.org>
Subject Re: [DISCUSS] deprecated function need more detail
Date Wed, 23 Nov 2016 10:13:36 GMT
+1 That sounds excellent.

On Wed, 23 Nov 2016 at 11:04 Till Rohrmann <trohrmann@apache.org> wrote:

> +1 for your proposal.
>
> Cheers,
> Till
>
> On Wed, Nov 23, 2016 at 9:33 AM, Fabian Hueske <fhueske@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 <shijinkui666@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message