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 <and...@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.v...@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 <st...@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@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
