[hibernate-dev] Search: to follow or not to follow latest Lucene index format

[Sanne Grinovero]

2011/7/8 Emmanuel Bernard <emmanuel at 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