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

Vlad Mihalcea mihalcea.vlad at gmail.com
Wed Jun 28 03:55:06 EDT 2017


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
>


More information about the hibernate-dev mailing list