Perhaps we can have an "active" NH3.x.x branch, we will see the activity there... Each committer can chose to fix something there and MUST fix it even in trunk (NH4). Each committer can fix something in the trunk and then CAN backport it in the branch (it can be backported even by another committer).
If the NH3.x.x has enough activity we can maintain it alive; if the NH3.x.x has no activity we will release it and the rip it. Something saying to me that this is a "dejá vu"... the good intention are great... the reality does not match always On Thu, Oct 14, 2010 at 9:23 AM, Stephen Bohlen <[email protected]> wrote: > 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 > . -- Fabio Maulo
