Re: [hibernate-dev] Removing deprecated methods from Session and SessionFactory

On 8 May 2015 at 18:33, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > I don't know if I agree with this. I'll play the other side... What if you > had done the Lucene 4 upgrade and spent a bunch of time managing API changes > and finally got it right and then Lucene 4.1 cam along and removed a bunch > of deprecated methods? I think I'd actually be a tad more pissed off at > this scenario. Maybe that's just me? And realize that alot of the methods > that are deprecated and being discussed have actually be deprecated in > before 4.0 even. That's a long time... If that would have happened, I'd open the source code before upgrading, get my IDE to highlight deprecated methods and resolve them. I would have been able to remove a dozen trivial ones, then run the testsuite to confirm.. then remove a tricky one, run the testsuite to confirm.. etc.. When I'm done, I upgrade to Lucene 4.1 and test again. I would have loved that! Think about the opposite: you code flat out for two weeks, and then you have some test failing in a very mysterious way; then it's like "ok, one of these 40,000 lines of changes is wrong". It took us 2 months of work, or almost a year if you include finding an appropriate moment in which you can actually afford to block any other activity for no other reason than an upgrade. Sanne > > On Fri, May 8, 2015 at 11:47 AM, Sanne Grinovero <sanne(a)hibernate.org&gt; > wrote: >> >> 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 <hardy(a)hibernate.org&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev