Interesting point...though I wonder (aloud) if surrendering the advantage of "NH can be your fully-featured ORM solution if you're not on .NET 4 yet whereas EF4 requires .NET 4" is the right choice from an adoption standpoint...?
Having a hard requirement on .NET 4 is empowering for the project's (potential) capabilities, but is likely to be limiting in its potential adoption -- at least for a while. My own prediction (remains to be seen, of course) is that the present (and immediate future) financial climate in the global economy will make the adoption-curve of .NET 4 a lot flatter than the adoption of .NET 2 was (meaning that taking a hard dependency on .NET 4 is likely to be adoption-limiting for a longer period of time than it had been for just about any prior .NET upgrade cycle). Based on what I'm hearing out there, very few people are looking longingly at .NET 4 and saying "I have to have that in my company immediately" and I'm skeptical that EF4, MVC3, and a few other MS technologies that are .NET 4-only will (quickly) change their minds. Though the next obvious question is "how many of these stuck-in-the-mud, trapped-in-the-past enterprises are even candidates for adopting something like NH in the first place?" All that said, as a non-commercial software project, adoption is merely one of many metrics NH can chase, so I think a choice either way is entirely defensible. My two cents. -Steve B. -----Original Message----- From: Fabio Maulo <[email protected]> Sender: [email protected] Date: Thu, 14 Oct 2010 08:18:36 To: [email protected]<[email protected]> Reply-To: [email protected] Subject: Re: [nhibernate-development] Re: Planning NH next if you want compare NH with EF, in some way, you need at least EF4 (running on .net4) -- Fabio Maulo El 14/10/2010, a las 01:40, Julian <[email protected]> escribió: > You've raised a good point. So who do we want to make happy? If NH > doesn't make anybody happy, it will be consigned to obscurity by > Entity Framework. > > On Oct 14, 12:33 pm, Fabio Maulo <[email protected]> wrote: >> I don't want see a single #ifdef inside NH sources. >> Here, in Argentina, I know at least a big company where the tech department >> have not approved the usage of .NET3.5... well they must be happy with >> NH2.1.2 >> If the company where you are working can't approve the usage of .NET4 >> well... you must be happy with NH3.0.x or you have to find somebody to >> maintain NH3.0 for you. >> >> Make happy everybody is outside NH scope. >> >> -- >> Fabio Maulo >> >> El 13/10/2010, a las 18:34, Diego Mijelshon <[email protected]> >> escribió: >> >> I understand the concerns. >> Still, I'd like to point out a few things that put us in a better position >> this time: >> - We can have VS2010 as a requirement for NH_development_, but still >> produce 3.5 assemblies (VS2010 finally has_real_ multitargeting). Maybe we >> can switch versions with a small script. >> - The differences between .NET 3.5 and .NET 4.0 are limited to a couple >> files that might reference ISet<T> (unless we start messing with dynamic and >> things like that). >> >> That's for the technical side... >> Now, if_only_ 50% of the users want to target .NET 4, it means the other >> half are still on 3.5, which means it should still be supported (again, >> maybe NH 4 can change that, but only if NH 3 is supported until most >> developers are using .NET 4) >> >> Diego >> >> >> >> On Wed, Oct 13, 2010 at 12:52, Fabio Maulo <[email protected]> wrote: >>> To community. >>> If there is a lesson learned in the past of NHibernate is that we (team) >>> can't maintain not only two mayor versions for long time, but even we can't >>> maintain two set of solutions (VS2008, VS2010 for example). >> >>> Perhaps we can try again but I'm inclined to think that it will be not >>> possible, we have suffered it from VS2003(net1.1) to VS2005 (net2.0) and we >>> then avoid to suffer the same from VS2005 (net2.0) to VS2008 (net3.5), I'm >>> inclined to avoid it again. >> >>> This is OSS and who want maintain an old NH version can do it without any >>> kind of problems at list from our side (team). >> >>> We can't stop the evolution. NET4 is out there since long time and in a >>> poll we saw 50% of users voting to have NH3 pointing .NET4. >>> We will follow the evolution with courage and without pay a high cost for >>> back-draw compatibility. >> >>> On Tue, Oct 12, 2010 at 3:49 PM, Fabio Maulo <[email protected]> wrote: >> >>>> Hi *team*. >> >>>> You have around 30 days to talk with people to have some ideas about what >>>> each one is thinking about NH next. >>>> The main matter is not about improvements, features or issues in general >>>> but about the "other" big JUMP. >>>> Perhaps after 3.0.0, this time, we may wait a little bit before open the >>>> 3.x branch and start developing NH4... >>>> Perhaps we have to plan only a little minor release after 3.0.0GA... >>>> something like one month or month and half to release 3.0.1 with some bug >>>> fix. >> >>>> Personally I would release NH4.0.0 very quickly with one mayor >>>> change: Remove Iesi.Collection (sig) for external usage... >>>> That mean (phase1): >>>> 1) a separated ICollectionTypeFactory for back draw compatibility and to >>>> give the opportunity to convert existing projects >>>> 2) Adios no strongly typed <set> (no Iesi ? well... only the ISet<T> will >>>> be supported) >>>> 3) The <set> will mean .Net4 ISet<T> by default >>>> 4) No more support for .NET3.5 >> >>>> (phase2) >>>> After NH4.0.0 we can start the real hard work but it will be "only" >>>> internal... the remotion of the reference to Iesi.Collection >>>> We may walk some others routes but I prefer a drastic cut instead a long >>>> torture. >> >>>> During phase2 I would implements some others ideas but that will be matter >>>> of appropriate discussions. >> >>>> The other possibility is to give support to both (Iesi and .Net) >>>> ISet differentiating it through a specific <type>... in any case it mean: >>>> bye bye .NET3.5 >> >>>> Please try to avoid a quick answer and take your time to "digest" the >>>> matter. >> >>>> -- >>>> Fabio Maulo >> >>> -- >>> Fabio Maulo .
