What if you'll give people more choice? If there is no branch maintained/updated regularly by NH commiters, anybody can *fork** it and start maintaining it himself. This means no "official" branch releases unless back-ported. But at least you'll leave a choice to community - if somebody wants it, he should have it *with minimal fuss*...
* fork is available in D(eveloper-friendly)VCS and best used with github/bitbucket. On Thu, Oct 14, 2010 at 2:45 PM, Fabio Maulo <[email protected]> wrote: > 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 > >
