Hm, I was hoping that HORN would be the solution for that kind of problem...
I had this upgrade paralysis back when Castle still was a single trunk project, I just had it with Castle, NH and Rhino alone. To overcome it, I created a NAnt file that did what HORN does now. -Markus 2010/3/4 Paul Cowan <[email protected]>: > Thanks for the reply Michael, I (obviously) think this is a conversation > worth having. > But surely you are not saying that in order to use a stack with many castle > parts, I need to, and I quote: > > "create a fork of each project (from a tag, release, > branch, trunk, wherever), and integrate them so they all work > together" > > I know how to do this and have but I do not want to. It is also intensified > by all the other OSS projects that use castle like nhibernate, rhino and the > rest. Must I retrieve the source of these projects and then use PSake or > whatever else is du jour in order to rebuild my stack? > > Surely we can do better than that? Other platforms do. > > Ruby is better because the RubyGems package manager takes care of the > installation of reusable libraries called gems. It is a joy to work with. > It is easier in Ruby because they are working with code files and not > binary files but it is truly amazing and shows how poor horn is in > comparison. > > If nobody else sees this as a problem and just an occasional challenge then > I will be quiet. > > At the moment I have a stack that if anything uses too much OSS. I am > paralysed in my upgrade path. > > Surely that last statement is an oxymoron? > > Cheers > > Paul Cowan > > Cutting-Edge Solutions (Scotland) > > http://thesoftwaresimpleton.blogspot.com/ > > > > On 4 March 2010 14:04, Michael Maddox <[email protected]> wrote: >> >> Paul, >> >> Managing dependencies is time consuming at best, extremely difficult at >> worst. >> >> That is why so many people avoid dependencies like the plague. >> >> Krzysztof said that he thinks two months is long enough to update >> dependencies, and while that feels reasonable, it's just not. >> Updating dependencies is a distraction. It doesn't, in general, make >> end users lives better. It's "make work". >> >> Any project focused on making user's lives better is going to avoid >> dependencies and waste as little time managing dependencies as >> possible. That means they aren't likely to upgrade to the latest >> version of a dependency unless there is a solid user focused reason to >> do so (and personally I always fret about regressions from new bugs in >> the new version). >> >> So, if you are forced to take on dependencies, your only recourse is >> to aggressively manage those dependencies. >> >> I think HornGet is a fantastic piece of engineering and I honestly >> don't know enough about Ruby to know why life is theoretically better >> there, but I know this problem fundamentally can't be made to go away. >> >> It should be possible for any reasonably experienced developer to take >> the Castle stack, create a fork of each project (from a tag, release, >> branch, trunk, wherever), and integrate them so they all work >> together. This isn't a version number issue or a release cycle issue >> so much as it is a "does the thing compile and pass all integration >> tests" issue. >> >> It takes time and effort and doesn't necessarily feel like things are >> moving forward. >> >> -Michael Maddox >> http://www.capprime.com/software_development_weblog/ >> >> 2010/3/3 Paul Cowan <[email protected]>: >> >>> What else do you think could Castle project do? >> > >> > I always wonder why this does not seem to be such a big problem in Java. >> > How do they not have these versioning problems given their inherent >> > similarities? >> > >> > As far as castle is concerned, it would make sense to have a versioned >> > build >> > of everything. That is we can say that all castle libraries are at the >> > same >> > version. >> > >> > At the moment, we have 3 versions of castle core 1.2, 1.4 etc. and >> > different >> > versions of castle windsor 2.1, 3. >> > >> > This seems very disconnected. Should there not be a build that is all >> > at >> > the same version? >> > >> > In the grand scheme of things, I think ALL .NET OSS needs to work >> > together >> > to try and alleviate this nightmare. There are a multitude of great >> > initiatives being held back by all working at different versions of >> > shared >> > libraries. >> > >> > Releases should not happen every month, that is, we do not say there is >> > 2.1 >> > finished this week, lets go straight on to 3 next and 3.1 the week >> > after. >> > >> > Maybe working to stricter interfaces would help for binary >> > compatibility. >> > >> > There are soooooooooooo many different versions of the boo libraries >> > kicking >> > around it is crazy. >> > >> > I like the idea of a shared repo where people can pull their shared >> > libraries from rather than just going to the OSS project of choice and >> > pulling down the latest which is why we are where we are. >> > >> > Getting a delivery mechanism for .NET OSS like ruby gems is currently >> > practically impossible due to .NET's assembly model and the wild west >> > approach of dependency management. >> > >> > I know because I have tried! >> > >> > Any thoughts? Am I alone in thinking this is something that really >> > needs >> > cracked on a large scale? >> > >> > Cheers >> > >> > Paul Cowan >> > >> > Cutting-Edge Solutions (Scotland) >> > >> > http://thesoftwaresimpleton.blogspot.com/ >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Castle Project Development List" group. >> To post to this group, send email to >> [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/castle-project-devel?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/castle-project-devel?hl=en. > -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
