[ https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christopher Currens updated LUCENENET-480: ------------------------------------------ Assignee: Christopher Currens I think this can be done for the release. Right now, all that needs to be done is creating the build configurations for 3.5 (or a tool to create them) and update the build/release scripts. Also, if there's time, making Contrib.Spatial work in 3.5 would be nice. There are a few parts that rely on the TPL and Concurrent collections that aren't present in 3.5. We can get a lot of the behavior to work, at the expense of slightly slower collections. A dictionary with locks will, in nearly all cases, be several hundred-thousand milliseconds slower in just about all operations. If this is ported to 3.5, it should probably be mentioned and recommended that .NET4 be used. > 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.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3 > Reporter: Christopher Currens > Assignee: Christopher Currens > Attachments: SortedSet.cs > > > 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