NightOwl888 commented on issue #284: URL: https://github.com/apache/lucenenet/issues/284#issuecomment-667202834
> Sorry, I mean the Java Lucene version. I am seeing that the latest Java Lucene is 8.6.0. Does Lucene.Net 4.8.0 match Lucene 4.8.0? The core Lucene.Net project is based on 4.8.0. Most of the submodules including `Lucene.Net.Analyisis.Common` are based on 4.8.1. Some of the other analysis modules were ported from 7.2.0 and 8.2.0 (which were the latest at the time we ported them). > I am asking because I cannot believe it falls behind so much. That is the battle we are fighting. People get the impression that we are far behind because of the number of years it has taken and the fact there are 4 major versions between Lucene.NET and Lucene. Last I checked (I believe it was 8.3.0), there were exactly 7 new modules and about 12 new features of any consequence added since 4.8.0. That's it. Look at the source code if you don't believe it. There was a discussion back in 2018 that I wasn't part of where some people said they are withholding their support because we are not targeting the latest version. I am curious to know whether they realize: - Lucene.NET 4.8.0 is almost stable and has been since that conversation happened in 2018 - We have been working on Lucene.NET's dependencies since then (that both 4.8.0 and 8.x require) - It would take around 1800 hours to upgrade from 4.8.0 to 8.x, not including the 1100-1200 hours we have yet to complete now - Changing gears now will rob the .NET community of a stable Lucene.NET 4.8.0 in 2021, and take at least an extra year to stabilize and roll out - We are planning to upgrade to 8.x after the release of Lucene.NET 4.8.0 is stable and we have secured enough funding to get started - 8.x has only about 12 new features that 4.8.0 doesn't have that are of any consequence I am curious to know which of the 12 or so new features that people think are so important that they are withholding their support, and how they could ever think it would be worth it for us to derail the whole project for at least a year to try to reach that goal. Not to mention robbing the entire .NET community of a stable 4.8.0 while they wait for that work to be completed. Our sponsors at Microsoft doesn't agree with those people. They don't even agree with us that it is worth it to upgrade to 8.x after the release of 4.8.0. Sure there are bug fixes and performance benefits in the new version, but the total benefit for the cost just isn't there. Unfortunately the gap between the reality of the situation and the impression that people get about how far we are behind is a big one, and that situation isn't going to change until we either reach a stable 4.8.0 or the community provides enough funding for the extra 1800 hours of labor involved in re-targeting to 8.2.0. ---------------------------------------------------------------- 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]
