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

[Steve Ebersole]

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
>