" What this boils down to (for me) is this: what will make this project stronger -- maintained compatibility with existing implementations, or migrating to a more current framework? Lest history repeat itself, migrating to a current framework is the best approach."
I completely agree. "Developer enjoyment" is a top priority for my org and in our experience .NET 4 is much more enjoyable then .NET 2 - however this was not a scientific study :). Since this project has lacked activity for large periods of time, I really feel that we need to focus somewhat on developer enjoyment as well. Maintainers need to have fun too. Ryan Hoffman Software Architect The New Teacher Project (718) 233-2821 | rhoff...@tntp.org | www.tntp.org Evaluation systems are broken - so how do we fix them? Teacher Evaluation 2.0 -----Original Message----- From: Jeff Rodenburg [mailto:jeff.rodenb...@gmail.com] Sent: Thursday, May 12, 2011 11:11 AM To: lucene-net-user@lucene.apache.org Subject: Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4 Neal's arguments are reasonable, but this full conversation goes to the heart of the matter -- what's the goal here? I believe the goal is to ensure Lucene.Net can succeed as a long-term project going forward, so this question should focus on how to best achieve that. For those who may not have been around this project for any length of time, discussion about supported frameworks and future direction in Lucene.Net is not new. Neal and others maintain that lowest-common-denominator is the best approach, but history has shown otherwise. A similar decision was reached by others (at the time, it was a consideration between .Net 1.1 and pushing forward to .Net 2.0). The LCD approach won out -- in no small part -- because interested parties were concerned about compatibility with projects at their current employment. As a result, participatory development in the project waned. "Suffered" is a more apt description, to the point that the project nearly got kicked out of the ASF for lack of forward progress. Make no mistake, believing this (a decision to maintain on the legacy framework) wouldn't have a negative impact on forward growth of the project is patently false. What this boils down to (for me) is this: what will make this project stronger -- maintained compatibility with existing implementations, or migrating to a more current framework? Lest history repeat itself, migrating to a current framework is the best approach. - j On May 12, 2011, at 7:21 AM, Granroth, Neal V. wrote: > Let the vote decide. > > In general backwards compatibility is always the best policy. However, the > cost to the project, maintaining a separate branch, in my opinion is too > high. A better approach would be to keep the main trunk .NET 2.0 compatible; > those that want to compile to .NET 4.0 are free to do so. This way all users > are supported with minimal effort. As Lucene.NET is a port, not independent > development the dubious advantages of .NET 4.0 are not particularly > significant. > > Locking Lucene.NET to 4.0 does not pose any difficulty for the products I am > responsible for, as they are tied to version 1.9.1 for several more years at > least. It simply means that, as I can no longer compile the code (as I > discovered with 2.9.4g), that I would then no longer be able to assist the > project with occasional tests, benchmarks, and usage questions. > > C'est la vie. > > - Neal > > -----Original Message----- > From: Digy [mailto:digyd...@gmail.com] > Sent: Wednesday, May 11, 2011 5:31 PM > To: lucene-net-user@lucene.apache.org > Subject: RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After > Apache Lucene.Net 2.9.4 > >> If you want to take on managing this branch because your company >> demands > it then put up your hand. > I expect the same from 4.0 enthusiasts also :) Here is the branch > https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene. > Net_2_ > 9_4g > > DIGY > > -----Original Message----- > From: Ken Foskey [mailto:kfos...@tpg.com.au] > Sent: Thursday, May 12, 2011 1:12 AM > To: lucene-net-user@lucene.apache.org > Cc: lucene-net-user@lucene.apache.org > Subject: Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After > Apache Lucene.Net 2.9.4 > > > On 12/05/2011, at 12:16 AM, "Granroth, Neal V." > <neal.granr...@thermofisher.com> wrote: > >> That's a fantasyland perceptive. In the real world there are many, >> huge > organizations (the clients to whom we sell various products, including > one optional package that incorporates Lucene.NET) who tie themselves > to older versions (Windows95 is the oldest in-production platform of > which I'm aware). The market is clearly demanding products and support > for older systems. >> >> - Neal >> >> -----Original Message----- >> From: Ryan Hoffman [mailto:rhoff...@tntp.org] >> Sent: Tuesday, May 10, 2011 6:20 PM >> To: lucene-net-user@lucene.apache.org >> Subject: RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After >> Apache > Lucene.Net 2.9.4 >> >> I feel like if you're in an org that is limiting you to be on .NET2 / > CLR2, then guess what, you're stuck with the latest Lucene.NET for CLR2. > Too bad. That latest release obviously is working fine for you right > now, otherwise why did those business decisions make that a dependency > in the first place. You're also missing out on countless other > libraries who have shifted to .NET 4, which you are stuck on the > latest CLR2 versions of. The rest of the world has moved on, and > guess what, we don't need to be held back because there are a few people left > behind. > > It is possible to maintain a v2 or even v3.5 branch. This could be > supported as the community makes the effort. A few patches won't be 4 > specific, majority I expect. If you want to take on managing this > branch because your company demands it then put up your hand. > > It sounds like v4 offers advantages in performance and personally I > need to go 4 for other projects anyway. Not supporting v4 would be > frustrating from the simple iswhitespace function to full libraries= >
