lucenenet-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shad Storhaug <s...@shadstorhaug.com>
Subject RE: State / Future of the Lucene.Net Project
Date Tue, 29 May 2018 18:59:12 GMT
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:farhad.khalafi@gmail.com] 
Sent: Tuesday, May 29, 2018 9:59 PM
To: user@lucenenet.apache.org
Cc: dev@lucenenet.apache.org
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 <bodewig@apache.org> 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
>
Mime
View raw message