Details
-
Task
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3
-
None
Description
We need to investigate what needs to be done with the source to be able to support both a .NET 3.5 and 4.0 build. There was some concern from at least one member of the community (see here) that we've alienated some of our user base by making such a heavy jump from 2.0 to 4.0. There are major benefits to using 4.0 over the 2.0-based runtimes, specifically FAR superior memory management, particularly with the LOH, where Lucene.NET has had major trouble with in the past.
Based on what has been done with Lucene.NET 3.0.3, we can't (easily) drop .NET 3.5/3.0 libraries and go back to 2.0. HashSet<T> and ISet<T> is used extensively in the code, that would be a major blocker to get done. I suppose it could be possible, but there hasn't been a whole lot of talk about what runtimes we intend to support. The big change between lucene 2.x and 3.x for java was also a change in runtimes, that allowed generics and enums to be used in the base code. We have a similar situation with the API (it's substantially different, with the addition of properties alone) for this next version of Lucene.NET, so I think it's reasonable to at least make a permanent move from 2.0 to 3.5, though that's only my opinion, hasn't been discussed with the committers.
It seems that supporting 3.5 and 4.0 should be fairly easy, and is a decent compromise in supporting both a 2.0 and 4.0 runtime. At the very least, we should try our best to support it.