The other option for people not wanting a line-by-line port is to just stick with whichever the last version that had a line-by-line transliteration done to it. This is done in a number of projects where new versions break compatibility. 2.9.4 is certainly a nice release...
-r On Thu, Dec 29, 2011 at 4:32 PM, Troy Howard <thowar...@gmail.com> wrote: > Thinking about it, I should make myself more clear regarding why I > brought up IKVM again, just so no one gets the wrong idea about my > intentions there... > > I only mentioned it as a justification for dropping line-by-line > compatibility and as an alternative for people who really care about > that. As we discussed previously, IKVMed Lucene is not Lucene.Net in a > lot of important material ways. We are already deviating significantly > from Java Lucene even with the "mostly line by line" approach. Compare > Lucene.Net 2.9.4 and IKVMed Java Lucene 2.9.4. They are very different > user experiences on a lot of levels (licensing, packaging, data types > used, etc). > > But it's a *reasonable alternative* when a high-degree of consistency > with Java Lucene is important to the end user and by pointing to IKVM > as our answer to those users, we are free to move forward without that > concern. > > That means, supposing we move away from Java significantly, as a new > end user looking to employ Lucene in their .NET product, they can > choose between IKVM Lucene (identical API to Java, can use the latest > Java build, performs well, may have some problems with licensing and > packaging) and Lucene.Net (different API but hopefully one that is > more palatable to .NET users so it'd be easy to learn, perfoms better > than IKVM, but has a dev cycle that lags behind Java, possibly by a > lot). > > Existing users who like who Lucene.Net as it is now, may feel > alienated because they would be forced to choose between learning the > new API and dealing with a slow dev cycle, or adapting to IKVM which > could be very difficult or impossible for them. Either one would > require a code change. But of course, we run this risk with any change > we make to what we are doing. I think a greater risk is that the > project lacks direction. > > Anyway, it's just one idea/talking point towards the end goal of > getting the general topic off the table completely. > > Thanks, > Troy > > > On Thu, Dec 29, 2011 at 3:32 PM, Troy Howard <thowar...@gmail.com> wrote: > > Apologies upfront: another long email. > > > > My most firm opinion on this topic is that, as a community, we spend > > too much time on this discussion. We should just simply commit to one > > or the other path, or both, or some middle ground, or just commit to > > not discussing it anymore and go with "whatever code gets written and > > works is what we use" and leave it up to the discretion of the coder > > who is actually spending time improving the product. Obviously the > > last option is the worst of them. > > > > My view of our current roadmap is/was: > > > > 1. We'd maintain basic line-by-line consistency through the 2.x > > releases. But 3.X and beyond were open to changing the API > > significantly. We are committed to changing the API and internal > > implementations in order to improve performance and developer > > experience on .NET, but haven't yet had made a plan for that (eg, no > > spec for a new API). > > > > 2. We'd try to automate the porting process so that it was repeatable > > and easy to keep up with (or at least easier) and maintain a > > line-by-line port in a branch. That means the .NET version would > > ultimately be a very different product than the line-by-line port and > > we'd be creating two separate but related products but where possible, > > share code between them. Patching the line-by-line product from Java > > would be easier and faster than patching the .NET product and so they > > may end up with different release schedules. > > > > It seems that effort on improving automation of the port has tapered > > off. As anyone who has done any of the porting from commit patches > > from Java knows, a good portion of that work can be automated with > > find/replace but substantial portions and certain scenarios is the > > current code definitely cannot be and probably will never be able to > > be fully automated. > > > > While I have been advocating "doing both" and trying to find a > > strategy that makes sense for that, another option is to just > > officially drop any concern for line-by-line consistency with Java. A > > justification for that is simple: IKVM provides this already. The > > licensing allows use in commercial apps and it's performance is close > > to the same, so, AFAIK it's a viable replacement for a line-by-line > > version of Lucene.Net in just about any context as long as no one is > > modifying IKVM itself. I don't think it's unreasonable to suggest to > > people who want a line-by-line version to use IKVM instead of > > Lucene.Net. > > > > So, if we use that perspective and say that the need for a .NET usable > > line-by-line version of Lucene is already available via IKVM, why > > would we bother handcoding another one? It makes more sense to focus > > our valuable hand coding work on making something that *improves* upon > > the .NET development experience. It may cause us to be slow to > > release, but for good reason. > > > > So it seems to me we have the following primary agenda items to deal > with: > > > > 1. Make an official decision regarding line-by-line porting, publish > > it and document our reasoning, so that we can end the ambiguity and > > circular discussions > > 2. If line-by-line porting is still part of our plan after we > > accomplish Agenda Item #1, resume work on improving automation of > > porting, creating scripts/tools/etc and document the process > > 3. If having a different API for .NET is still part of our plan after > > we accomplish Agenda Item #1, spec those API changes and associated > > internal changes required and publish the spec > > > > And to drive home the point I made in my first sentence: If had > > already accomplished those three agenda items, the time I just spent > > typing this email could have been spent working on Lucene.Net. We need > > to get to that point if we want to maintain any kind of development > > velocity. > > > > Thanks, > > Troy > > > > > > On Thu, Dec 29, 2011 at 2:38 PM, Prescott Nasser <geobmx...@hotmail.com> > wrote: > >> I dont think at the end of the day we want to make just cosmetic > changes. We also have the issue of same name different casing which needs > to be fixed - but it's not clear how to manage that without some large > adjustments to the API. > >> > >> > >> > >> Sent from my Windows Phone > >> ________________________________ > >> From: Troy Howard > >> Sent: 12/29/2011 2:19 PM > >> To: lucene-net-...@lucene.apache.org > >> Subject: Re: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g > >> > >> 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 > >>> >
