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

[Steve Ebersole]

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 at 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.vlad at 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 <steve at 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 at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>