Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
------------------------------------------------------------------------------
Key: LUCENENET-480
URL: https://issues.apache.org/jira/browse/LUCENENET-480
Project: Lucene.Net
Issue Type: Task
Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo,
Lucene.Net Test
Affects Versions: Lucene.Net 2.9.4g, Lucene.Net 2.9.4, Lucene.Net 3.0.3
Reporter: Christopher Currens
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|http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201202.mbox/%3C004b01cce111$871f4990$955ddcb0$@fr%3E])
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
