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

Christian Beikov christian.beikov at gmail.com
Wed Jun 28 14:28:03 EDT 2017


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



More information about the hibernate-dev mailing list