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 <st...@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 <sa...@hibernate.org> > wrote: >> >> On 8 May 2015 at 18:33, Steve Ebersole <st...@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 <sa...@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 <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 >> > >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
