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&gt; 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&gt; 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&gt; >> 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 >> > >