Farhad, > 1. The current version of Lucene.Net is 3.0.3 which was released on October 10, 2012. I am assuming this was on par with the Java code of the same version.
Correct. > 2. The current effort that you describe is targeting 4.8.0 and possibly 4.8.1 of the Lucene codebase. Correct. There have been some discussions about upgrading the project to 4.8.1, and there are only about 120 files that differ between the versions. We are somewhere in the middle now because a lot of the recent contributions were brought over from 4.8.1. The differences to the Lucene core library were significant, though and IMO it would be best to wait until we have released 4.8.0 before considering a full upgrade to 4.8.1. The performance benefits will probably be worth the relatively minor effort before upgrading to a higher major version of Lucene. > 3. The current Java version of Lucene is 7.3.1. Correct. However the hump we are just about over is the big one. There were major changes to the project structure from 3.x to 4.x and the project size also increased by more than a factor of 10. By contrast, the changes to the project structure are minor going forward. I tried getting a line comparison the same as I did between 4.8.0 and 4.8.1, but it was thrown off by the fact that code comments have been restructured and other changes that have no effect on the actual executable code. So it is hard to get a feel for how much change is there from the repo. That said, the structure and layout of the classes is easily more than 90% the same. I am confident the project can be upgraded to the latest version without going through a complete port again after the release by doing file by file comparisons and porting only the diff into Lucene.Net. I have outlined the procedure here: https://github.com/apache/lucenenet/pull/174#issuecomment-251614795 I don't see any real reason why the next jump couldn't be all the way to the latest Lucene version in a small fraction of the time it took to port 4.8.0 by changing the individual files and leaving the project structure relatively unchanged. > Are we going to attract a significantly larger community of users as we move to version 4.8.1? I would say that is a resounding yes. There have been several reports of bugs/performance issues in 3.0.3. Not to mention, we have heard lots of positive feedback about how much better the performance is (for the most part) from 4.8.0. The download count (of all versions) was averaging about 600 per day 2 years ago. Now it is up to 950 per day. The bulk of the downloads are 3.0.3, but getting 4.8.0 out of pre-release will certainly change that. > We will also be competing with active projects like Elastic Search for .NET (NEST) project. Maybe low-level access to Lucene core is not that important anymore? This is a good point, and may be a factor in the number of contributions we have been getting. However, keep in mind the numbers that Stefan are throwing out there are CONTRIBUTIONS BY PMC MEMBERS, there have been several contributions by non PMC members over the past year. The download counts indicate the popularity of Lucene.Net as a dependency is growing significantly despite being stuck at 3.0.3. Another factor is that having an integrated solution will always outperform an HTTP API based platform such as Elastic Search, and for many that makes all the difference in the decision. Also, I noticed one other NuGet projects are now targeting Lucene.Net 4.8.0-beta00005: https://www.nuget.org/packages/Kalix.Leo.Lucene/11.0.10-alpha, which means there is another potential contributor out there. Another consideration: You don't really have to know much about Lucene or Java to be a part of the porting effort. Most of the work can be done with the help of Google or by searching the codebase to find out how other similar pieces of code were ported. At this stage in the game, we mostly just need people to thoroughly test, report, and fix bugs. Thanks, Shad Storhaug (NightOwl888) -----Original Message----- From: farhad khalafi [mailto:[email protected]] Sent: Tuesday, May 29, 2018 9:59 PM To: [email protected] Cc: [email protected] Subject: Re: State / Future of the Lucene.Net Project Stefan, Thank you for your help in keeping this project alive up to this point and trying to re-ignite some interest in moving it forward. I have a few questions that will influence the extent of my possible involvement with this project. 1. The current version of Lucene.Net is 3.0.3 which was released on October 10, 2012. I am assuming this was on par with the Java code of the same version. 2. The current effort that you describe is targeting 4.8.0 and possibly 4.8.1 of the Lucene codebase. 3. The current Java version of Lucene is 7.3.1. As I am not very familiar with advanced features of each version, could you summarize what major enhancements are included as you move from 3.0.3 to 4.8.1 to 7.3.1 The version numbers are abstract and don't tell much about feature gaps as we try to play catch with the Java version. Are we going to attract a significantly larger community of users as we move to version 4.8.1? What will be missing as compared to the current Java version? I fully appreciate the amount of work involved in porting this code even when using automated tools. I am just not sure that once the task is accomplished, the users will not dismiss it as an already "outdated version". We will also be competing with active projects like Elastic Search for .NET (NEST) project. Maybe low-level access to Lucene core is not that important anymore? Thanks again, Farhad On Tue, May 29, 2018 at 7:26 AM, Stefan Bodewig <[email protected]> wrote: > On 2018-05-28, Alberto León wrote: > > > Me too, but please, make easy to prepare the environment, I love code by > I > > hate the sysadmin things > > :-) > > As I said in a different mail I'm afraid we lack hands, so I doubt > anybody will magically appear and streamline the build process. > > From what I understand building and running tests should work fine as > long as you've got .NET Core and Powershell installed in Windows - if > this is not your environment things become tricky. I'd recommend you try > building and if things don't work as expected ask on the dev list. > > Stefan >
