I agree with idea of NHibernate "package", but only along with a traditional "NHibernate only" one.
What do you think about NuPack package management? Will it be practical to have a package with NH, NH Contrib, Fluent/codeconform and what else people uses the most? On Wed, Oct 13, 2010 at 11:41 AM, Frans Bouma <[email protected]> wrote: > Major releases (e.g. 3.0, 4.0) should have a significant amount of > features, > otherwise it's just a point release. I wouldn't go for 4.0 with just 1 > change, that should be a point release (e.g. 3.1). As the assembly is > signed, people have to manually upgrade from 3.0 to 3.1 anyway, so it's not > as if people will run into big problems when installing 3.1 next to 3.0 > > For 4.0, as I've said in the NHusers list before (but I got ripped apart > because of it), what's really needed is a turn-key package, so when someone > downloads NHibernate, everything is in there, and the developer can just > turn things on or off through configuration. No more hunting down contribs > from all over the place, which have mismatching dependencies (e.g. what was > the case with FNH 1.0 for example), just 1 package, 1 source for the goods, > and nothing else. > > The longer you wait, the harder it will be to get new users in and keep > existing users on-board. In todays world, developers don't want to spend > hours looking for libraries supporting their NH code, if a competing o/r > mapper has everything in 1 box: time is money. > > Another, IMHO major, point is that it should be forbidden to post a > blogpost > about a new feature unless the new feature is also properly documented with > official docs. The current docs are outdated, and it's a massive job to get > it up to par, but the longer you wait, the bigger this gap will become, and > it will again turn into a situation where a developer has to hunt down > blogposts for documentation about that specific feature or setting. > > If NH takes itself serious and as a professional framework, it should get > itself together and promote itself as one: proper, up to date docs, proper > one-stop download site and configuration so getting started and getting up > and running with all cilinders running is easy and quick. > > I know this all will take a lot of time, but IMHO it's time well spend, at > least better spend than on some edge case feature only 3 people will ever > use or yet another way to query your domain. > > FB > > > 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 > > > > >
