+1 Sent from my iPhone
On 10 maj 2011, at 19:19, Ryan Hoffman <rhoff...@tntp.org> wrote: > 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 > --------------------------------------------------------- >
