You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by GitBox <gi...@apache.org> on 2021/12/13 00:58:12 UTC

[GitHub] [lucenenet] NightOwl888 commented on issue #437: When is the release version planned?

NightOwl888 commented on issue #437:
URL: https://github.com/apache/lucenenet/issues/437#issuecomment-992014580


   We are working on 4.8.0-beta00016 at present and will likely be releasing it within the next couple of weeks.
   
   - Since we have completed #288 (at least to the point where we can debug), we were able to detect and repeat test failures well enough to fix nearly all known bugs.
   - We have tracked down some of the concurrency problems, but there is an issue with the documents writer that is preventing us from allowing more than 1 thread from utilizing it (we are unable to apply [this change](https://dev.azure.com/shad0962/Experiments/_git/lucenenet/commit/80270e932a44b25c016fcb273772575f3c712e04?refName=refs%2Fheads%2Ffix%2Fthreading-merge-2) without running into deadlocks).
   - We have been digging into several of the boxing/unboxing issues for numeric types and dates that were introduced by doing a direct port from reference type to value type, and are close to fixing these issues.
   - [J2N](https://github.com/NightOwl888/J2N) is stable pending an API review.
   - [ICU4N](https://github.com/NightOwl888/ICU4N) is still an alpha and although we don't need to port any more of it, it has many issues to complete. The most critical are:
     1. There are some thread safety issues when using [BreakIterator](https://github.com/NightOwl888/ICU4N/blob/ad0250a0823c7638a5de0e3682d7b6ad8d8d06be/src/ICU4N/Text/BreakIterator.cs) from [ICUTokenizer](https://github.com/apache/lucenenet/blob/be977b8becae15a86659b4843e6d2033f89f84d3/src/Lucene.Net.Analysis.ICU/Analysis/Icu/Segmentation/ICUTokenizer.cs) see #269. We have worked around by adding a static lock so only 1 thread can utilize it at a time.
     2. The package structure needs refactoring back to 1 ICU4N package and 1 or more data packages so we don't have to include duplicate data with every target framework.
     3. The data loading needs to be fixed so end users can supply their own data subsets to minimize distribution size. The current thinking is to upgrade to at least ICU 64 and to utilize the `.jar` file that is generated by the [ICU Data Build Tool](https://unicode-org.github.io/icu/userguide/icu_data/buildtool.html) so we don't have to build an additional tool for ICU4N.
   - [Lucene.Net.Analysis.OpenNLP](https://www.nuget.org/packages/Lucene.Net.Analysis.OpenNLP) depends on [IKVM](https://www.nuget.org/packages/IKVM/), which currently has no .NET Core/.NET 5/.NET 6 support. We recently [got ownership of the IKVM NuGet package](https://github.com/ikvm-revived/ikvm/issues/40), but need a working .NET Core build so we can release it. Alternatively, someone could do the high-level analysis of what it would take to use one of the alternative options so we can avoid dealing with IKVM. See #460.
   - We need to review tests #259 and `IDisposable` usage #265 and could really use some help with these tasks.
   - `TokenStream` didn't call `close()` on `Reader` in Java, but ours calls `TextWriter.Dispose()`. We need to investgate what is supposed to close the reader and apply the appropriate fix (see https://github.com/apache/lucenenet/issues/271#issuecomment-973005744).
   - We also need to add tests for MAUI #258 to ensure we don't have any infinite recursion problems with the way we are using generics (they are not fully supported on Mono/Xamarin.Android, see https://github.com/NightOwl888/J2N/commit/9fa5f07c588fd187ea9c33d5c82d02e444f749c7). Leave a comment on #258 if interested, I have some insights on how this can be achieved if there are no test runners for MAUI that support NUnit 3.x (Xamarin only had runners for NUnitLite, which is not compatible with our test framework). 
   
   While we don't consider `Lucene.Net.ICU` and `Lucene.Net.Analysis.OpenNLP` to be blocking the release, it would take a considerable amount of effort to be able to release them on a different schedule as the rest of the components (probably around 30% of the work as it would take to just complete them). Several components depend on `ICU4N`, including `lucene-cli` which also has index maintenance tools that should be version synced with Lucene.NET.
   
   We are always looking for additional people to help us reach the goal. Per community request on the mailing list to provide a list of features that they could work on so they could help, we obliged by moving from JIRA to GitHub issues and marking issues up for grabs. While we are committed to completing Lucene.NET, if you are waiting for us to complete it with the small number of resources we have, make no mistake about it you **will** be waiting. On the other hand, we have recently added some information on the [NuGet Readme](https://www.nuget.org/packages/Lucene.Net/) page on how to get involved and/or sponsor the project if you wish to help us to make Lucene.NET 4.8.0 a production release faster.
   
   


-- 
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.

To unsubscribe, e-mail: dev-unsubscribe@lucenenet.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org