Re: [hibernate-dev] Continue to add 5.2 deprecations for 6.0 work?
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev