Any reason we can't continue this g branch and make it more and more .net like? 
I was thinking about what we've expressed at goals - we want a line by line 
port - it's easy to maintain parity with java and easy to compare. We also want 
a more .NET version - the g branch gets this started - although it's not as 
.Net as people want (I think). 

 

What if we used the g branch as our .Net version and continued to make it more 
.Net like? and kept the trunk as the line by line? The G branch seems like a 
good start to the more .Net version anyway - we might as well build off of that?

 

 

 

 

---------------------------------------- > From: digyd...@gmail.com > To: 
lucene-net-dev@lucene.apache.org > Date: Thu, 29 Dec 2011 02:45:23 +0200 > 
Subject: RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g > > > but I guess the 
future of 2.9.4g depends on the extent that it is becoming > more .NET like > > 
My intention while I was creating that branch was just to make 2.9.4 a > little 
bit more .Net like(+ maybe some performance). > I used many codes from 3.0.3 
Java. So it is somewhere between 2.9.4 & 3.0.3 > But I didn't think it as a 
separate branch to evolve on its own path. It > is(or I think it is) the final 
version of 2.9 > > DIGY > > -----Original Message----- > From: Christopher 
Currens [mailto:currens.ch...@gmail.com] > Sent: Wednesday, December 28, 2011 
9:20 PM > To: lucene-net-dev@lucene.apache.org > Cc: 
lucene-net-u...@lucene.apache.org > Subject: Re: [Lucene.Net] Lucene.Net 3 
onwards and 2.9.4g > > One of the benefits of moving forward with the 
conversion of the Java > Lucene, is that they're using more recent versions of 
Java that support > things like generics and enums, so the direct port is 
getting more and more > like .NET, though not in all respects of course. I'm of 
the mind, though, > that one of the larger annoyances, Iterables, should be 
converted to > Enumerables in the direct port. It makes it a pain to use it in 
.NET > without it inheriting from IEnumerable, since it can't be used in a 
foreach > loop or with linq. Also, since the direct port isn't perfect anyway, 
it > seems a port of the IDEA of iterating would be more in the spirit of what 
> we're trying to accomplish, since the code would pretty much be the same, > 
just with different method names. > > I sort of got off topic there for a 
second, but I guess the future of > 2.9.4g depends on the extent that it is 
becoming more .NET like. > Obviously, while java is starting to use similar 
constructs that we have > in .NET, it will never be perfect. Admittedly, I 
haven't looked at 2.9.4g > in a little while, so I'm not sure how much it now 
differs from 3.x, since > there's a relatively large change there already. > > 
Thanks, > Christopher > > On Thu, Dec 22, 2011 at 9:13 PM, Prescott Nasser > 
wrote: > > > > > That's a great question - I know a lot of people like the 
generics, and I > > don't really want it to disappear. I'd like to keep it in 
parity with the > > trunk. But I know we also have a goal of making Lucene.Net 
more .Net like > > (further than 2.9.4g), and I don't know how that fits in. We 
are a pretty > > small community and I know everyone has some pretty busy 
schedules so it > > takes us considerable time to make big progress. Trying to 
keep three > > different code bases probably isn't the right way to go. > > > > 
> > > > > Date: Fri, 23 Dec 2011 13:02:03 +1100 > > > From: mitiag...@gmail.com 
> > > To: lucene-net-u...@lucene.apache.org > > > Subject: [Lucene.Net] 
Lucene.Net 3 onwards and 2.9.4g > > > > > > I was browsing "Roadmap" emails 
from November in Lucene developer list. > > It > > > remains unclear in what 
state Lucene 3 porting is , but my question more > > > about 2.9.4g . > > > Is 
it kind of experimental dead end variation of 2.9.4 with generics ? > Am > > > 
I right in classifying it as more .Net like 2.9.4 which is unrelated to > > > 
roadmap Lucene 3 porting effort. > > ----- > > Checked by AVG - www.avg.com > 
Version: 2012.0.1901 / Virus Database: 2109/4708 - Release Date: 12/28/11 >     
                                

Reply via email to