NightOwl888 edited a comment on issue #270: URL: https://github.com/apache/lucenenet/issues/270#issuecomment-817336573
Agreed. Although, since Lucene already has created a CheckIndex utility to confirm compatibility using hashes, we should just leverage that rather than trying to mock a way to make our index byte-by-byte compatible with one from Java. The gap that could potentially happen is small - we are already using zipped index files that were created in Java to test with, so we know that binary reading is compatible. However, there is a small chance that we have introduced the same binary writing bug in both the production code and the tests and it would be good to confirm that the CheckIndex util in Java works to load indexes that were created in .NET on a continual basis. The idea is to build a test module once for this, and use it to confirm binary compatibility with Lucene in each release after 4.8.0. Provided Lucene doesn't radically change their design again, this will be the last full port of Lucene to .NET - all future Lucene.NET releases will just be an upgrade of this one. We will be able to keep pace with Lucene's release schedule, but that will only happen if we automate time-consuming manual processes like checking for binary compatibility and make them part of our nightly build. Since breaking binary compatibility in a patch is unacceptable, this absolutely needs to be done prior to the 4.8.0 release. We don't really think that any new Java applications will load indexes from Lucene.NET 4.8.0, but as @rclabo pointed out, there are index utilities that exist in the wild that we need to be compatible with as well as the ability to load indexes that were created in Lucene.NET 4.8.0 in the next major release of Lucene.NET. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
