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 >
