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

[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.vlad at 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 <steve at 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 <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
>>>>
>>>
>>>
>