Re: [hibernate-dev] Continue to add 5.2 deprecations for 6.0 work?
Vald, while I personally completely agree with you that @Deprecated is the
proper approach (imo), some users do not. @EndOfLife offers a *possible*
alternative. Yes using @EndOfLife does not warn users of using deprecated
features unless they do something "extra" as I mentioned in my original
email.
The question is whether @EndOfLife is an appropriate "middle ground"
On Wed, Jun 28, 2017 at 4:56 AM andrea boriero <andrea(a)hibernate.org> wrote:
In my opinion deprecating something is useful only when we are able
to
provide an alternative, not sure about the best approach in case we do not
have a current alternative.
On 28 June 2017 at 08:55, Vlad Mihalcea <mihalcea.vlad(a)gmail.com> wrote:
> I would use the regular Java deprecation mechanism is just make sure
> we write the plan in the Javadoc and the User Guide.
>
> On example is Query#setResultTransformer:
>
> >
> > * @deprecated (since 5.2)
> > * @todo develop a new approach to result transformers
> > */
> > @Deprecated
> > Query<R> setResultTransformer(ResultTransformer transformer);
>
> If we didn't use deprecated here, and chose only @EndOfLife,
>
> people might complain even more that they didn't ackowledged that this
> method is going to be changed in future.
>
> Vlad
>
>
>
> On Tue, Jun 27, 2017 at 5:15 PM, Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
> > Per subject I wanted to come to a consensus as to how exact we want to
> be
> > in terms of continuing to add deprecations to 5.2 for ongoing 6.0 work.
> > Considering that these deprecations are meant to be a guide for users to
> > migrate to 6.0 I think we should try to be as complete as possible in
> this
> > effort, but wanted to hear other's views.
> >
> > An alternative is the @EndOfLife annotation I have recently added to
> 6.0.
> > We could back port this annotation and use that instead; the reason
> being
> > that people complain when we deprecate something without being able to
> > specify its "replacement". This would be an option to do both. The
> > drawback is that this annotation obviously has no tie-in with javac -
> users
> > would have to go out of their way to find these.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>