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

[Sanne Grinovero]

Right, seems we agree then; mine is purely a quantitative approach:
don't break too much in a single version, but if these have been
deprecated already my comment doesn't apply.

Sanne

On 8 May 2015 at 19:30, Steve Ebersole <steve at hibernate.org> wrote:
> Sanne, the methods are already deprecated.  You can already do that step.
> For the deprecated methods that actually have a replacement anyway.
>
> But think about the ones that don't.  They are the ones that are likely to
> "still be there" on the API and likely do absolutely nothing.  Because if
> there was a corollary, we would have named it in the deprecation message
> when we deprecated it.
>
> I mean following your logic (assuming that we are good citizens) you would
> always do a first step of upgrading to the latest bugfixz release of the
> previous release family.  That version will have the deprecations in place.
> For example, if I want to upgrade to 5.0 I would first upgrade to the latest
> 4.3 and fix any deprecations.  *Then* I can update to 5.0.  Its exactly what
> you described just in reverse.  Except that it allows us to actually clean
> up trash :)
>
>
>
> On Fri, May 8, 2015 at 12:59 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> 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
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>