lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Currens (Created) (JIRA)" <>
Subject [jira] [Created] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
Date Fri, 23 Mar 2012 18:57:29 GMT
Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible

                 Key: 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|$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

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

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message