Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
+1 (According to Digy's suggestion) On Mon, May 9, 2011 at 10:04 PM, Troy Howard thowar...@gmail.com wrote: All, Please cast your votes regarding the topic of .Net Framework support. The question on the table is: Should Apache Lucene.Net 2.9.4 be the last release which supports the .Net 2.0 Framework? Some options are: [+1] - Yes, move forward to the latest .Net Framework version, and drop support for 2.0 completely. New features and performance are more important than backwards compatibility. [0] - Yes, focus on the latest .Net Framework, but also include patches and/or preprocessor directives and conditional compilation blocks to include support for 2.0 when needed. New features, performance, and backwards compatibility are all equally important and it's worth the additional complexity and coding work to meet all of those goals. [-1] No, .Net Framework 2.0 should remain our target platform. Backwards compatibility is more important than new features and performance. This vote is not limited to the Apache Lucene.Net IPMC. All users/contributors/committers/mailing list lurkers are welcome to cast their votes with an equal weight. This has been cross posted to both the dev and user mailing lists. Thanks, Troy
Re: [Lucene.Net] Lucene.NET 2.9.4g -- only usable with .NET 4.0 ?
Am I correct that your trial code changes make this version of Lucene.NET incompatible and un-buildable with any version of .NET prior to 4.0? As I understand it, 2.9.4g only replaces non-generic collections with generic ones. Generics was introduced in .NET Framework 2.0. Oh, sorry, I took a look at the code just to make sure. It does use SortedSet, a .NET 4 feature. It also uses HashSet, introduced in .NET 3.5. Kind regards, Amanuel
Re: [Lucene.Net] release 2.9.4
Builds fine. Three failed tests, Lucene.Net.Index.TestIndexWriterReader.TestDuringAddIndexes and Lucene.Net.Index.TestIndexWriter.TestFutureCommit and Lucene.Net.Store.TestWindowsMMap (MMapDirectory does not seem to be ready for the world yet) Related: What is the Hudkins status? On Tue, Apr 5, 2011 at 9:23 PM, Wyatt Barnett wyatt.barn...@gmail.com wrote: Tag [+1] svn export and command line build successful; I'll keep you all posted . . . On Tue, Apr 5, 2011 at 3:07 PM, Troy Howard thowar...@gmail.com wrote: Yes. Once we're ready to call this revision an RC, it should be tagged as such. Wyatt: Thanks for helping to test! Looking forward to your results. Thanks, Troy On Tue, Apr 5, 2011 at 11:37 AM, Granroth, Neal V. neal.granr...@thermofisher.com wrote: No, the URL in DIGY's email apepars correct and the SVN revision appears to be 1086410. Question: Should there be a tag for Lucene.Net_2_9_4 as there are for previous release candidates? - Neal -Original Message- From: Wyatt Barnett [mailto:wyatt.barn...@gmail.com] Sent: Tuesday, April 05, 2011 12:15 PM To: lucene-net-dev@lucene.apache.org Cc: digy digy Subject: Re: [Lucene.Net] release 2.9.4 Thanks. For anyone watching, the corrected clickable link is https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C%23/. Also, just to make sure we are looking at this right, the revision we should be using is 1089138 -- main thing is I've been in and out of town, not caught up on anything and I'd hate to start building stuff against the wrong version . . On Tue, Apr 5, 2011 at 1:10 PM, digy digy digyd...@gmail.com wrote: Sorry, no binaries. You can download the source from https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C#/src/Lucene.Net DIGY On Tue, Apr 5, 2011 at 12:12 AM, Wyatt Barnett wyatt.barn...@gmail.comwrote: Actually about to dive into a big search tweaking spike in a certain project here, happy to do it on 2.9.4. Got binaries? On Mon, Apr 4, 2011 at 12:27 PM, Troy Howard thowar...@gmail.com wrote: We don't have any sort of QA report on the latest build. DIGY called for testing, but I haven't seen anyone respond to that request indicating successful testing. So, how do we want to manage this? In the business world, we'd never think of making a release without extensive QA first. In my other open source projects, either we've managed QA ourselves by 'switching hats' for a couple weeks prior to release, or just crossed our fingers because the user base was too small. Lucene.Net is a fairly high-profile project, with a large user base. I think it would not be responsible to make a release without a formal QA process. We do have extensive unit tests, but do you think those are sufficient to cover our QA needs? Should we try to find community members with a specialty in software testing that would be willing to fulfill this role on our project? Should we just swap hats? I didn't worry about this issue with the latest 2.9.2 release because it was QAed by the user base for a long time before it was an 'official release'. Maybe this is an effective tactic? Release first, and let the user base roll in bug reports fixing them on yet later minor maintenance releases? This seems to be the method a lot of projects use (i.e. no specific QA process, but rather an organic process of 'try our best then deal with bug reports later'). What do we think about this? Thanks, Troy On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser geobmx...@hotmail.com wrote: Hey all, I know we have a number of outstanding JIRA issues, but I think most of them have been handled for the 2.9.4 release? Do we have anything outstanding that is holding back a new release? ~P
[Lucene.Net] [jira] [Commented] (LUCENENET-391) Luke.Net for Lucene.Net
[ https://issues.apache.org/jira/browse/LUCENENET-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13013628#comment-13013628 ] Amanuel Workneh commented on LUCENENET-391: --- A 2.9.2-version of Pasha's code can be found at https://bitbucket.org/mammo/lukesharp I think that code can be used with some work. Should we continue with this? Also, using Pasha's code would, if I understand things correctly, make the resolution of LUCENENET-397 easier. Luke.Net for Lucene.Net --- Key: LUCENENET-391 URL: https://issues.apache.org/jira/browse/LUCENENET-391 Project: Lucene.Net Issue Type: New Feature Components: Lucene.Net Contrib Reporter: Pasha Bizhan Assignee: Sergey Mirvoda Priority: Minor Labels: Luke.Net Fix For: Lucene.Net 2.9.4 Attachments: luke-net-bin.zip, luke-net-src.zip Create a port of Java Luke to .NET for use with Lucene.Net See attachments for a 1.4 compatible version or https://bitbucket.org/thoward/luke.net-incbuating for a partial implementation that is 2.9.2 compatible. The attached version was contributed by Pasha Bizhan, and the bitbucket version was contributed by Aaron Powell (above version is a fork, original at https://bitbucket.org/slace/luke.net). If source code from either is used, a software grant must be provided from the original authors. The final version should be 2.9.4 compatible and implement most or all features of Java Luke 1.0.1 (see http://code.google.com/p/luke/ ). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Commented] (LUCENENET-391) Luke.Net for Lucene.Net
[ https://issues.apache.org/jira/browse/LUCENENET-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009224#comment-13009224 ] Amanuel Workneh commented on LUCENENET-391: --- The bitbucket version is a WPF application and I suppose we want the resulting application to run under Mono. I suggest we use the Pasha Bizhan version. I have made a 2.9.2-version and if we agree that we want to continue with the Bizhan version work can begin. Luke.Net for Lucene.Net --- Key: LUCENENET-391 URL: https://issues.apache.org/jira/browse/LUCENENET-391 Project: Lucene.Net Issue Type: New Feature Components: Lucene.Net Contrib Reporter: Pasha Bizhan Assignee: Sergey Mirvoda Priority: Minor Labels: Luke.Net Fix For: Lucene.Net 2.9.4 Attachments: luke-net-bin.zip, luke-net-src.zip Create a port of Java Luke to .NET for use with Lucene.Net See attachments for a 1.4 compatible version or https://bitbucket.org/thoward/luke.net-incbuating for a partial implementation that is 2.9.2 compatible. The attached version was contributed by Pasha Bizhan, and the bitbucket version was contributed by Aaron Powell (above version is a fork, original at https://bitbucket.org/slace/luke.net). If source code from either is used, a software grant must be provided from the original authors. The final version should be 2.9.4 compatible and implement most or all features of Java Luke 1.0.1 (see http://code.google.com/p/luke/ ). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
