lucenenet-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Chiaretta <simone.chiare...@gmail.com>
Subject Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
Date Wed, 11 May 2011 16:41:26 GMT
Well, NH is for data access, as well as EF, they can be used on the client s well, to have
data access

From PiyoPad

On 11/mag/2011, at 18:25, Robert Jordan <robertj@gmx.net> wrote:

> [0]
> 
> On 11.05.2011 17:54, Simone Chiaretta wrote:
>> I just want to point out that the "keep the lowest common
>> denominator" approach is among the reasons that killed the "old" Lucene.NET.
>> 
>> I don't see a reason why we should stay on .NET 2 because there are
>> companies that cannot migrate.
>> NH 3 is just .NET 4, MVC 3 is just .NET 4, EF v4 is just .NET 4, Umbraco
>> v4.6+ is just .NET 4
> 
> These are mainly server frameworks. Since Lucene.Net is perfectly
> suitable for desktop applications, forcing a .NET 4 dependency
> is too early. Don't forget this target.
> 
> Robert
> 
>> 
>> If someone is still stuck on .NET 2.0, will still be able to use the latest
>> version that has been released: there must be a moment where older version
>> are discontinued.
>> Furthermore, if someone is on .NET 2.0, chances are that he will be just
>> maintaining and old product, not doing new developments on it, so will
>> probably won't upgrade to Lucene.NET 3 anyway.
>> 
>> Simone
>> 
>> 
>> On Wed, May 11, 2011 at 5:42 PM, Richard Wilde<richard@wildesoft.net>wrote:
>> 
>>> Correct "The market is clearly demanding products and support for older
>>> systems." But currently as the vote goes it's a minority...
>>> 
>>> 
>>> -----Original Message-----
>>> From: Granroth, Neal V. [mailto:neal.granroth@thermofisher.com]
>>> Sent: 11 May 2011 15:16
>>> To: lucene-net-user@lucene.apache.org
>>> Subject: RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache
>>> Lucene.Net 2.9.4
>>> 
>>> 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:rhoffman@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.
>>> 
>>> Ryan Hoffman
>>> 
>>> -----Original Message-----
>>> From: Moray McConnachie [mailto:mmcconna@oxford-analytica.com]
>>> Sent: Tuesday, May 10, 2011 3:15 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
>>> 
>>> In this case I must vote
>>> 
>>> [0]
>>> 
>>> Shifting to 4.0 isn't that great for those of us who like Neal have more
>>> complex production platform issues to consider - and in the wonderful world
>>> of business decisions, Lucene and its features may play only a small part.
>>> 
>>> I think we should probably have run two votes:
>>> 
>>> a) discontinue support for 2.0
>>> b) should we standardise on 3.5 or 4.0
>>> 
>>> I've not run into any awkward build issues on different versions of 3.5,
>>> but
>>> it seems quite likely the same problem if it exists for 3.5 will also come
>>> to be true for 4.0 after a few service packs.
>>> 
>>> Moray
>>> -------------------------------------
>>> Moray McConnachie
>>> Director of IT    +44 1865 261 600
>>> Oxford Analytica  http://www.oxan.com
>>> 
>>> 
>>> ----- Original Message -----
>>> From: Troy Howard [mailto:thoward37@gmail.com]
>>> Sent: Monday, May 09, 2011 11:26 PM
>>> To: lucene-net-dev@lucene.apache.org<lucene-net-dev@lucene.apache.org>;
>>> lucene-net-user@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
>>> 
>>> 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
>>>> 
>>> 
>>> ---------------------------------------------------------
>>> Disclaimer
>>> 
>>> This message and any attachments are confidential and/or privileged. If
>>> this
>>> has been sent to you in error, please do not use, retain or disclose them,
>>> and contact the sender as soon as possible.
>>> 
>>> Oxford Analytica Ltd
>>> Registered in England: No. 1196703
>>> 5 Alfred Street, Oxford
>>> United Kingdom, OX1 4EH
>>> ---------------------------------------------------------
>>> 
>>> 
>> 
>> 
> 
> 

Mime
View raw message