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
