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