So the testsuite is using an helper method "org.hibernate.search.test.SearchTestCase.getTargetLuceneVersion()" for all those cases in which the unfriendly Lucene API demands a version.
The test method is currently returning this constant: Version.LUCENE_31 The ConfigContext is using a default of Version.LUCENE_30 if the user doesn't specify any version in the configuration. ..and I recently updated the Lucene dependency to 3.3, without changing these values. Now if we really want to keep them in sync, we could use Version.LUCENE_CURRENT; but this is deprecated, not because it's going to be removed but because there are implications in using it, so it's discouraged. It's also nice to be able to verify compatibility of Search's use of Lucene when using a backwards compatible index format. I think we're not tracking the latest version of Lucene with this flag, because we wanted to make sure we where backwards compatible. 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. 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? Cheers, Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
