Lucene.Net 3.0.3
I've started a wiki page, very rough, to help track the progress of 3.0.3. It also provides a link to the Issues that Lucene (java) 3.0.3 fixed from their previous release. https://cwiki.apache.org/confluence/display/LUCENENET/Lucene.Net+3.0.3 Roadmap: I agree we should probably all focus on one release at a time, until it is mostly finished, then move on to the next. Chris you bring up a good point "What does that mean" As for line-by-line port vs .NET version this is how I interpret the terms: -- line-by-line -- * Classes are mapped identical (where possible), no refactoring * We keep same types where possible (even if not optimal for .NET) * We don't refactor or condense code where possible - think linq queries vs various for loops and variable tracking. -- .Net Version -- * We use generics * We use .Net code and style conventions * We refactor everything that makes sense * Maintain 100% compatibility with Java Lucene index * It doesn't mean we significantly change the API Troy pointed out the benefits of NOT automating a java port, and if we can get up to parity, keep us in line shouldn't be too difficult. If we move towards a more .Net version, we are going to lose some of the ease of that porting. I'm personally ok with that, knowing that X causes a bug shouldn't be too hard to track down even if we refactor - it should be trivial to set up a quick test with our version and find out if the bug applies - if so, using the Java Lucene fix as guidance (was it an off by one error or something) can easily be ported into our code base (even if not copied and pasted as a line-by-line would allow). It's late, hopefully that makes some sense. Please add to it so we can continue to define what this means to us. When we understand what we mean by these terms and can really start to make decisions on where we are going. ---------------------------------------- > Date: Thu, 1 Dec 2011 09:57:37 -0800 > From: currens.ch...@gmail.com > To: lucene-net-dev@lucene.apache.org > Subject: Re: [Lucene.Net] 3.0.3 > > There are a few patches that were made for 2.9.4 between when the 3.0.3 > branch was forked from trunk and now that haven't been merged in. It looks > like I branched it on Nov. 7th, so > LUCENENET-431, LUCENENET-433, LUCENENET-453, and LUCENENET-455 may or may > not be fixed, since that also largely depends on what was ported (that code > may be removed, or changed in the new version). > > The Readme.txt, build.cmd line endings, and possibly the licence in > Contrib.SpellChecker.Test.nunit might need to be added as well. I still > need to make Jira issues for quite a few things, regarding 3.0.3, since > right now what is left do to is only stated in a few scattered emails and > text files in the repository. I was planning on doing that a few days ago, > but unfortunately life and work have gotten in the way. > > So regarding merging 3.0.3 into trunk, I'd probably like to fix those > first. I'm fine with merging 3.0.3 into trunk, though, I think a lot of it > is determined by our current AND long term goals. It makes sense to throw > 3.0.3 into trunk, but we're also already working on 4.0 in another branch. > On top of that, our board report shows that we still want the existing > line-by-line port (which the 3.0.3 branch is), as well as a .NET idomatic > API which is also mentioned in our long term goals as not just an API, but > a new .NET version. > > Now that we're finished with 2.x and we're in between versions, now is a > good time to talk about prioritizing our work. An important point Stefan > brought up last week, was that we are all working on x number of branches > in parallel, instead of all working together to get releases pushed, of > course we can still have branches but we are all kinda doing our own thing, > I'm guilty of this as well. We have a lot of goals, but there is seemingly > no priority for them (I realize current activities seems like a higher > priority than long term goals, but it just happened that way, and was never > discussed between all the committers). > > What is more important? The line-by-line port or the fully .NET-ified > version of Lucene? Should we start on the .NET version now? And what is > meant by .NET version? Is it simply API differences or significant > internal changes, as well? I'm not sure everyone has the same idea on > this, but it's *very* important we all do, and each way requires a > significantly different amount of work to accomplish. Additionally, and > I'm being very frank about this, our goals of having a line-by-line port > *and* a .NET version may or may not be possible with the current number of > committers we have, considering the amount of time everyone has to give to > the project differs greatly by so many factors (I'm not trying to attack > anyone, it's just how life works, I wasn't as active as I could have been > on the project until fairly recently, and I'm having a little less time > than I had a few weeks ago). > > I think it's important we discuss this and make sure everyone is on the > same page (it's possible we already are, and just haven't officially > documented it anywhere). Then I think we can move forward as a group in > the project. > > > Thanks, > Christopher > > On Thu, Dec 1, 2011 at 12:33 AM, Prescott Nasser <geobmx...@hotmail.com>wrote: > > > > > With 2.9.4 out the door, do we merge 3.0.3 into the trunk? How do we want > > to handle this?
