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.
