I think we are talking of different things. You're complaining about multiple versions of core, which has only has only one live release, the 1.2. Same about Windsor: In a six months window, only two versions were released, and all our stack works against the released version.
Cheers, Henry Conceição On Thu, Mar 4, 2010 at 11:41 AM, Paul Cowan <[email protected]> wrote: > Marcus, > > Horn can and should be used. > > But not everything is compiling and I honestly do not know where to point > the descriptors to. > > My points are this and please choose to ignore them as the ramblings of a > mad Irish man: > > 1. Creating multiple versions quickly like Castle.Core 1.2, 1.3, 1.4 is > confusing. > 2. Having multiple versions of other castle libraries like castle.windsor > with different named versions 2.1, 3.0 is confusing. > 3. No way of being to use multiple versions of the castle stack is not good > at best. > > As I said earlier, I love Castle but it is becoming impossible to use. > > I have heard this criticism from others. > > It is useful feedback and if nothing else, an interesting problem to solve. > > Cheers > > Paul Cowan > > Cutting-Edge Solutions (Scotland) > > http://thesoftwaresimpleton.blogspot.com/ > > > > On 4 March 2010 14:35, Markus Zywitza <[email protected]> wrote: >> >> 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. >> > > -- > 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.
