Hi,
As we had discussed a while ago, I have created a dedicated JIRA component
for each of our backends in OGM.
This means we don't have to encode the backend in issue titles anymore.
Thanks to Hardy's release script, the component name will be added to issue
titles in the change logs. Just make
OK, done: https://github.com/hibernate/hibernate-orm/pull/944 (I just
squashed the commits of Laurent into one)
This PR is for 4.3 as we originally wrote it for 4.3. I already ported it
to 5 but I prefer waiting we have settled everything before submitting the
other PR for 5 (the merge requires a
An ANT user on the forums got in trouble several times, first with
Lucene versions vs Hibernate Search, then fixed that he upgraded ORM
to 5 as well to align with Search 5 only to see Validator blow up at
bootstrap.
https://forum.hibernate.org/viewtopic.php?f=9&t=1039286
I'm thinking if we should
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 improveme
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 a
On 8 May 2015 at 18:33, Steve Ebersole 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 me
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 w
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 wrote:
> Sanne, the methods are already deprecated. You can already do t
