Re: [hibernate-dev] Search: to follow or not to follow latest Lucene index format
2011/7/8 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>
> It's also nice to be able to verify compatibility of Search's use of
> Lucene when using a backwards compatible index format.
We don't have tests (today) that keep old index formats and run against the new
version of HSearch. So the verification is an illusion :)
I don't think we have to verify binary formats, that's Lucene's own
business. I'm just wondering how to deal with this nasty API properly.
> I think we're not tracking the latest version of Lucene with
this
> flag, because we wanted to make sure we where backwards compatible.
I thought CURRENT would be removed by the Lucene team actually.
No, I specifically asked this on #lucene, the intention is to keep it
but discourage people from using it.
> Given we're now having the option to break backwards
compatibility,
> should we start tracking the latest version of Lucene, and log a
> warning if the configuration value is not set?
> As the Lucene developers suggest, we should recommend coding this
> value in the configuration.
Right we can improve the doc here.
And log a warning: if people where configuring it explicitly, then
Search would be able to continue providing "drop in" upgrades (even
better than before).
>
> Also because Hibernate Search now seems to work equally well with all
> Lucene 3.0.x, 3.1.x and 3.3.x, we should either consider only the
> latest supported, or test for the others too:
> worth having an environment parameter to be able to run the testsuite
> with older Lucene versions, or run it in mixed environments of newer
> Lucene versions but configured as older versions?
It's a lot of work/resource for not that much value IMO.
Ok, then I'll just make sure the constants are in sync and pointing to CURRENT.
Sanne