Of course we can delete them, I just meant to stress there should be a different "appropriate moment" for: A] removal of deprecated methods for the sake of it (cleanup of old garbage) B] removal of a method during a major release (API changes allowed) because we can't otherwise get some improvement
When a new major release comes - say Hibernate ORM 5.0 - we'll have quite a bit of "B" changes, as they are unavoidable and desired. If we also make all changes in category A, the steer amount of changes might become a critical mass which scare off people from upgrading. Speaking as a user who regularly codes as a client for such changes (for example Lucene 4 was a rather dramatic "fix" with over 2,000 compilation problems in Hibernate Search), I can swear that it's very nice if I can upgrade my application by fixing *some limited* compilation failures, and then run my testsuite. Then rinse and repeat... if I have to code 2 weeks straight w/o being able to run my tests I'll despair. So for ORM I'd not immediately delete all deprecated methods: let it be easy for people to upgrade to 5 as that's an intimidating process; let them realise that with a couple of changes they can do it. Once they're over the scary part, you can remove the long deprecated methods in some minor. But if any of these methods is a hindrance to get improvements done, no mercy :) Sanne On 5 May 2015 at 19:38, Hardy Ferentschik <ha...@hibernate.org> wrote: > On Tue, May 05, 2015 at 08:36:27AM -0500, Steve Ebersole wrote: >> Why? Why even deprecate methods then? > > +1 > > --Hardy _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
