lucenenet-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Foskey <kfos...@tpg.com.au>
Subject Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
Date Mon, 09 May 2011 22:37:00 GMT
+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 <thoward37@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.granroth@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:me@aaron-powell.com]
>> Sent: Monday, May 09, 2011 4:41 PM
>> To: lucene-net-dev@lucene.apache.org; lucene-net-user@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: aazzap@hotmail.com
>> 
>> -----Original Message-----
>> From: Troy Howard [mailto:thoward37@gmail.com]
>> Sent: Tuesday, 10 May 2011 6:05 AM
>> To: lucene-net-dev@lucene.apache.org; lucene-net-user@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
>> 
> 
> 

Mime
View raw message