Re: [hibernate-dev] Continue to add 5.2 deprecations for 6.0 work?

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.vlad(a)gmail.com&gt; 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 <steve(a)hibernate.org&gt; > 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 <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 >>>> >>> _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev