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

[Sanne Grinovero]

On 8 May 2015 at 18:33, Steve Ebersole <steve at hibernate.org> 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 at hibernate.org>
> 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>