lucenenet-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shad Storhaug <s...@shadstorhaug.com>
Subject RE: v4.8 BETA stability and migration implications
Date Sun, 11 Jun 2017 08:39:39 GMT
Alex,

While we have had a beta version for quite some time, it wasn't downloaded by many users,
so we don't have much feedback at this point as to how many bugs are remaining and how serious
they are. There are over 6900 tests that all pass, although we have a few that still fail
under certain random conditions. We haven't had any major complaints after the first 1000
downloads, but on a project with over 350,000 lines of code we will need several 10s of thousands
of downloads to be sure we have adequately tested the most significant features, and having
that amount of feedback within 3 months is a bit optimistic.

That said, we do need people like you to pave the way and thoroughly test Lucene.Net in production
projects to ensure it is stable, and to contribute in other ways to make it production-ready.

> The Lucene project docs (
> https://lucene.apache.org/core/5_4_0/changes/Changes.html#v4.0.0-alpha)
> suggests that there is a migration available but it causes a performance hit, and re-indexing
is the best way to go. Does that recommendation hold true for the Lucene.Net port?

Yes, there will definitely be a performance hit when using a 3.0.3 index, but there have also
been several performance improvements in Lucene 4.0 that may make it perform equal to or better
than 3.0.3.

One of the things left on the TODO list is to wrap the CLI tools into an executable that people
can use to maintain their indexes (including upgrading). There are more than a dozen tools
in Lucene. While these were all meant to be separate tools in Java, it might be easier to
maintain if we make a single "lucene.exe" console application that has several sub-commands
within it, similar to the "dotnet.exe" tool from Microsoft. For example "lucene upgrade-index
[options]". Of course, we should make the tools run on .NET Core so they are cross-platform.
It would also be good if we used ILMerge to make the executable work without any external
DLLs (assuming that is possible in .NET core).

> A related question about migration is whether there is a good changelog that indicates
what users of Lucene.net should expect when moving from
v3.03 to v4.8?

Since this is essentially a line-by-line port of Lucene, you can utilize the Lucene documentation
to make this assessment for the most part. But there is also a change log that is Lucene.Net
specific at: https://github.com/apache/lucenenet/blob/master/CHANGES.txt

Thanks,
Shad Storhaug (NightOwl888)


-----Original Message-----
From: Alex Reeser [mailto:areeser@cyrious.com] 
Sent: Friday, June 9, 2017 11:56 PM
To: user@lucenenet.apache.org
Subject: v4.8 BETA stability and migration implications

Hi, all.

I'm developing a new app that uses Lucene.Net, and I'm not sure if I can recommend to my CTO
that we make the plunge into the v4.8 beta. I would really like to because of the .NET Core
support, but I don't have a good idea on how stable the new version is.

Is there a feel as to how far away a public release is? My project here at work has a 3 month
time-frame until we get production users. What are the odds that v4.8 would be stable by then?

If the answer is "not good," then I'll happily wait to upgrade, but this prompts another question:
if I have production index data from v3.0.3, what's the migration like once v4.8 is out? The
Lucene project docs (
https://lucene.apache.org/core/5_4_0/changes/Changes.html#v4.0.0-alpha)
suggests that there is a migration available but it causes a performance hit, and re-indexing
is the best way to go. Does that recommendation hold true for the Lucene.Net port?

A related question about migration is whether there is a good changelog that indicates what
users of Lucene.net should expect when moving from
v3.03 to v4.8?

Thanks!
--
Alex Reeser
Software Developer | Cyrious Software
Mime
View raw message