[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