: We just made it random always, so it will fail consistently regardless : of JRE implementation.
Right, which means people who: * have an app that uses Lucene * have tests that use the Lucene test-framework * upgrade lucene w/o changing their app or their JVM ...could now get failures. : Adding CHANGES.txt to test changes seems like a slippery slope, the But this wasn't a "test change", this was a change to the published test-framework. : behavior and APIs here is undefined, we can and should break it at any : time we want without any hesitation or notice, and it should be : assumed that all things are random :) How is the API undefined? Starting with 3.1 the framework was specificly pulled out into it's own jar that was publicly advertised for lucene users to use... http://lucene.apache.org/java/3_3_0/api/test-framework/index.html "The Lucene Test Framework is used by Lucene as the basis for its tests. The framework can also be used for testing third-party code that uses the Lucene API." I agree that the back-compat on classes in test-framework should be loose, and we should be allowed to break compat anytime it helps improve our test coverage, but we should at least *mention* in CHANGES when we break it. right? -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
