My vote goes to merging the two: Apply the same concepts from 2.9.4g to 3.X development, using generics where possible, Disposable vs Close, and exposing *additional* APIs for generics (but leaving the existing old ones) to enable the underlying performance improvements the generics offer. Also, expose IEnumerable<T> implementations vs Java style enumerables/iterators.
If we are only adding to the existing and making relatively minor changes to enable generics, updating/maintenance should be relatively easy and it won't break anyone's code. Thanks, Troy On Thu, Dec 29, 2011 at 2:08 PM, Prescott Nasser <geobmx...@hotmail.com> wrote: > I agree its a matter of taste. I'd vote continue with g and evolve it to > where we want a .net version to be. What do others think? > > Sent from my Windows Phone > ________________________________ > From: Digy > Sent: 12/29/2011 1:16 PM > To: lucene-net-...@lucene.apache.org > Subject: RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g > > When I started that "g" branch, I had no intention to change the API, but at > the end it resulted in a few changes > like StopAnalyzer(List<string> stopWords), > Query.ExtractTerms(ICollection<string>) etc. > But I think, a drop-in replacement will work for most of the Lucene.Net > users (Of course some contribs have been also modified accordingly) > > Changing arraylists/collections with generic counterparts, GetEnumerator's > with foreach, AnonymousClass's with > Func<> or Action<>'s and Fixing LUCENENET-172 are things most people would > not notice. > > This "g" version includes also some other patches that were fixed for > .GE.(=>) Lucene3.1 (Which? I have to rework on my commits) > > So, there isn't much change in API, more changes for developers and more > stable code(At least I think so, since I use this "g" version in production > env. for months without any problem. For short, 2.9.4g is a superset of > 2.9.4 in bugfix level) > > > As a result, creating a new branch for .Net friendly Lucene.Net or > continuing on this branch is just a matter of taste. > > DIGY > > > > > > > -----Original Message----- > From: Scott Lombard [mailto:lombardena...@gmail.com] > Sent: Thursday, December 29, 2011 5:05 PM > To: lucene-net-...@lucene.apache.org > Subject: RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g > > > I don't see the g branch differing all that much from the line-by-line port. > All the g branch does is change some data types as generics, but line by > line the code the same once the generics are declared. > > I don't see 2.9.4g being any closer to a .NET style version than 2.9.4. > While it does generics use for list style variable types the underlying > classes are still the same and all of the problems with 2.9.4 not being .NET > enough would be true in 2.9.4g. > > I would have to refer to Digy on if it changes how an end user interacts > with Lucene.NET. If it does not affect how the end user interacts with > Lucene.NET then I think we should merge it into the Trunk and go from there > on 3.0.3. > > > Scott > > >> -----Original Message----- >> From: Prescott Nasser [mailto:geobmx...@hotmail.com] >> Sent: Wednesday, December 28, 2011 8:28 PM >> To: lucene-net-...@lucene.apache.org >> Subject: RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g >> >> >> 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-...@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-...@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 > >> > > ----- > > Checked by AVG - www.avg.com > Version: 2012.0.1901 / Virus Database: 2109/4710 - Release Date: 12/29/11 >
