2011/7/8 Emmanuel Bernard <emman...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
