[jira] [Commented] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
[ https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13414471#comment-13414471 ] Prescott Nasser commented on LUCENENET-480: --- Chris if you have the code running, is there any harm in integrating it back into the branch? 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. HashSetT and ISetT 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
[jira] [Commented] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
[
https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13397690#comment-13397690
]
Christopher Currens commented on LUCENENET-480:
---
Regarding the sorted SortedSet implementation, I might consider using a
{{SortedDictionaryT}} internally instead of a {{SortedListT}}. It's faster
at removals and insertions, at the cost of a little more memory. I think in
the cases where SortedSet is used in Lucene, it won't make much of a difference
at all in memory usage, but could use the speed.
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
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. HashSetT and ISetT 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
[jira] [Commented] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
[
https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13397164#comment-13397164
]
Christopher Currens commented on LUCENENET-480:
---
Change {{ISetT x = new HashSetT()}} to instantiate from a factory instead.
So, it would become something like: {{ISetT x =
Lucene.Net.Support.Compatibility.GetSetT()}}. In .NET 3.5 would return a
{{WrappedHashSetT : Lucene.Net.Support.ISetT}} (which in turn just wraps a
normal HashSetT). In .NET 4, it would just return a HashSetT.
We would need to do the same with SortedSet, as well.
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
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. HashSetT and ISetT 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
[jira] [Commented] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
[ https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13393683#comment-13393683 ] Prescott Nasser commented on LUCENENET-480: --- I agree, I'd prefer to leave ISet, however, if most of hte ISetT x = new HashSetT, I can't modify hashset to inherit from my own ISet Implementation. So I can either, 1. rewrite hashset to implement ISet (and inherit HashSet) or we can change the code from ISet. Attached is my incomplete SortedSet - i found it from another implementation based on sortedlist. 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 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. HashSetT and ISetT 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
[jira] [Commented] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
[ https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13393610#comment-13393610 ] Christopher Currens commented on LUCENENET-480: --- I would feel most comfortable leaving it as ISetT in most (all?) places, based on the one you've created, which I'm assuming follows the same contract as .NET 4? I can see Java possibly using more and more classes that aren't HashSet, that implement ISet. What did you wind up doing with SortedSet, did you write a class for it? 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 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. HashSetT and ISetT 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
[jira] [Commented] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
[ https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13393437#comment-13393437 ] Prescott Nasser commented on LUCENENET-480: --- ISetT set = new HashSetT(x) is all over the place - of course I realize this after I build an ISet interface. I'm reluctant to replace all the ISetT with HashSetT (I don't particularly like increasing the coupling), but since almost all of them are of the form ISetT = new HashSetT it would be pretty easy. Any one have any thoughts? The rest of the code changes are ready to roll, was just stuck figuring this one out. 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 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. HashSetT and ISetT 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
[jira] [Commented] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
[ https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13295135#comment-13295135 ] Prescott Nasser commented on LUCENENET-480: --- Attempting to compile the trunk in 3.5 yields 54 errors, however many of them are the same thing: 1. ISet doesn't exist in 3.5. I believe we can safely change all ISet to HashSet. 2. SortedSet doesn't exist in 3.5. There is no drop in replacement, we could either create a SortedSet class that inherits HashSet, we have to be careful how we implement this to avoid too big a penalty in sorting 3. Two internal Func's will have to be turned into actual methods, not anonymous functions 4. ThreadLocal - Digy nicely included a class ThreadLocal that we could put compile flags around if compiling for version 3.5 5. Task in the parallelmultisearcher would need to be replaced, I'm not sure atm how to accomplish that - we could remove this searcher all together in the 3.5 binary. Please provide further comments if you have any, otherwise I'm going to try and work on these this weekend 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 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. HashSetT and ISetT 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
[jira] [Commented] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
[
https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13295239#comment-13295239
]
Christopher Currens commented on LUCENENET-480:
---
I'm assuming we're going to define some sort of symbol to compile code if it's
3.5 vs 4.0. If so, we can do a few things to make it easier.
1. We can. The only reason we're using the interface is because Java is. I
can see in the future this might be a problem if we has to use a set class that
was not HashSet...but at least not it's not a problem. Alternatively, we can
write our own ISet class based on the .NET 4.0 one, and use a class that wraps
HashSet and implements ISet.
2. I think the only way to do this one is write our own, as you said.
3. We can just define these in the support class, when using .NET 3.5
{code}
public delegate TResult FuncT1, T2, T3, T4, T5, T6, T7, T8, T9, TResult(T1
arg1, T2 arg2, T3 arg3, T4 arg4,
T5
arg5, T6 arg6, T7 arg7, T8 arg8, T9 arg9)
public delegate TResult FuncT1, T2, T3, T4, T5, T6, T7, T8, T9, T10,
TResult(T1 arg1, T2 arg2, T3 arg3, T4 arg4,
T5 arg5, T6 arg6, T7 arg7, T8 arg8, T9 arg9, T10 arg10)
{code}
4. We can either use Digy's (I think it uses a WeakHashTable) or we can write
our own (more work), using Thread.AllocateDataSlot(). I believe that is how it
is done internally in .NET 4.
5. ParallelMultiSearcher does have the biggest changes between .NET 3.5 (and
actually Java's version of the class, because of the use of Tasks instead of
manually spawning threads). I feel like we could remove it from the 3.5
version (at least for now), or have two versions of 3.5, where one has a
dependency on the TPL for 3.5.
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
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. HashSetT and ISetT 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
[jira] [Commented] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
[ https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13295406#comment-13295406 ] Prescott Nasser commented on LUCENENET-480: --- Yes I think we should do this via a symbol #NET35 or some such. 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 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. HashSetT and ISetT 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
