+1. I think we should run a v2 branch from main for a while rather than polluting the code base. The v2 branch dies a natural death when parches are stopped being applied.
For the record I made v4 decision last night for my application. Ken Foskey On 10/05/2011, at 8:26 AM, Troy Howard <thowar...@gmail.com> wrote: > Yes, if you can't use a later framework, then you won't get the > benefits that come with that. One of the benefits that you may not get > is the latest version of the code with the least bugs. These are all > factors that a organization must take into account when considering > such policies. It's a tough choice to make, but even the most > conservative organizations need to move forward at some point. This is > the same issue that we all suffered through moving from 1.1 to 2.0... > Or moving from 32bit to 64bit... etc. > > If there is a real technical limitation (as opposed to a 'business > decision/policy'), then the best option is to branch from a previous > 2.0 compatible revision, and update the code to resolve whatever > issues you are encountering. Backporting from 3.5/4.0 code to 2.0 code > is not that difficult, especially when we have Mono available to work > from. Also, 2.9.4 (2.0 compatible) should have all the features of > 2.9.4g (4.0 compatible)... That is accomplished by setting the target > framework to 2.0, and using Mono implementations of HashSet/SortedSet > in the SupportClass.cs. So, until we get to Lucene.Net 3.X (next > version after 2.9.4), there will be support for 2.0 framework for all > changes/features. > > > For those with a situation similar to Neal's, I would consider option > [0] in the vote. This option proposes maintaining 2.0 compatibility > with patches/ifdef blocks, but still considering 4.0 as the primary > target framework. This seems like it would be ideal for those stuck > with limitations about framework support. It is unfortunately, the > option that requires the most amount of coding work and the most code > complexity. > > In general, I don't think we should consider targeting 3.5. One of the > problems with 3.5 compatibility is that depending on what version of > 3.5 you have (service packs, etc) you may get different results (eg, > can't compile with certain builds). So if we say "3.5" is our target > -- which 3.5? 4.0 may end up the same, but at the moment, it doesn't > have this problem. > > > Perhaps we should work up a "For the boss" page which explains, in > detail, the cost/benefit analysis of choosing a version of Lucene.Net > (and it's associated framework dependencies). This will assist folks > who are trying to justify a particular perspective (either for/against > using a particular version). Benchmarks, known bugs/bug fixes/features > list, etc.. > > > Thanks, > Troy > > > On Mon, May 9, 2011 at 2:52 PM, Granroth, Neal V. > <neal.granr...@thermofisher.com> wrote: >> That only works if you are *allowed* to deploy a new or updated .NET >> framework on the target system, which is not always true. >> >> But the problem is not really about deployment it is really more for those >> of us who must compile from source and who are not permitted to upgrade our >> development toolset. >> >> - Neal >> >> -----Original Message----- >> From: Aaron Powell [mailto:m...@aaron-powell.com] >> Sent: Monday, May 09, 2011 4:41 PM >> To: lucene-net-...@lucene.apache.org; lucene-net-u...@lucene.apache.org >> Subject: RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache >> Lucene.Net 2.9.4 >> >> +1 >> >> PS: If you are supporting .NET 3.5 then you get .NET 2.0 support anyway, you >> just have to bin-deploy the .NET 3.5 dependencies (System.Core, etc) since >> they are all the same CLR >> >> Aaron Powell >> MVP - Internet Explorer (Development) | Umbraco Core Team Member | FunnelWeb >> Team Member >> >> http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | MSN: >> aaz...@hotmail.com >> >> -----Original Message----- >> From: Troy Howard [mailto:thowar...@gmail.com] >> Sent: Tuesday, 10 May 2011 6:05 AM >> To: lucene-net-...@lucene.apache.org; lucene-net-u...@lucene.apache.org >> Subject: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache >> Lucene.Net 2.9.4 >> >> All, >> >> Please cast your votes regarding the topic of .Net Framework support. >> >> The question on the table is: >> >> Should Apache Lucene.Net 2.9.4 be the last release which supports the .Net >> 2.0 Framework? >> >> Some options are: >> >> [+1] - Yes, move forward to the latest .Net Framework version, and drop >> support for 2.0 completely. New features and performance are more important >> than backwards compatibility. >> [0] - Yes, focus on the latest .Net Framework, but also include patches >> and/or preprocessor directives and conditional compilation blocks to include >> support for 2.0 when needed. New features, performance, and backwards >> compatibility are all equally important and it's worth the additional >> complexity and coding work to meet all of those goals. >> [-1] No, .Net Framework 2.0 should remain our target platform. Backwards >> compatibility is more important than new features and performance. >> >> >> This vote is not limited to the Apache Lucene.Net IPMC. All >> users/contributors/committers/mailing list lurkers are welcome to cast their >> votes with an equal weight. This has been cross posted to both the dev and >> user mailing lists. >> >> Thanks, >> Troy >> > >
