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 <robe...@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<rich...@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.granr...@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: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. >>> >>> Ryan Hoffman >>> >>> -----Original Message----- >>> From: Moray McConnachie [mailto:mmcco...@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:thowar...@gmail.com] >>> Sent: Monday, May 09, 2011 11:26 PM >>> To: lucene-net-...@lucene.apache.org<lucene-net-...@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.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-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: 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-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 >>> --------------------------------------------------------- >>> >>> >> >> > >
