I think a deprecation with @Deprecated should be enough/is more appropriate for this.
Mit freundlichen Grüßen, ------------------------------------------------------------------------ *Christian Beikov* Am 28.06.2017 um 16:45 schrieb Steve Ebersole: > A rose by any other name... I am fine with either name - > > What we need to determine is whether the concept is valid, or if we just > keep with our current "deprecation strategy". In the past I have been > pretty insistent that @Deprecated is the proper approach. I am offering a > potential alternative to see what others think. > > > On Wed, Jun 28, 2017 at 9:18 AM Vlad Mihalcea <mihalcea.v...@gmail.com> > wrote: > >> The concept is good and we should apply it. Instead of @EndOfLife we >> could use @Deprecating >> as it suggests a continuing action has not finished yet, but the eventual >> outcome is obvious. >> >> Makes sense? >> >> Vlad >> >> On Wed, Jun 28, 2017 at 4:51 PM, Steve Ebersole <st...@hibernate.org> >> wrote: >> >>> 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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
