Thanks Krzysztof , I buy into a lot of what you say.
My point about the different versions, is that I still do not know how to get a build of the stack I mentioned at the beginning of the post. I do not know what parts are pointing to the trunk version of windsor for example and which parts are pointing to the trunk when in reality it seems to be a combination of the two. Am I an anomaly in that I use lots of the castle stack apart from castle windsor? My point is that it is impossible to treat castle seperately when in reality, I really use at least half of it. Saying Castle.Core is at 1.4 and Castle.Windsor is at 2.1 is confusing because I really use Castle as a whole. Cheers Paul Cowan Cutting-Edge Solutions (Scotland) http://thesoftwaresimpleton.blogspot.com/ 2010/3/4 Krzysztof Koźmic (2) <[email protected]> > Paul, > > - perhaps a slight modification to how Horn works could solve this > issue (at least to some degree). > Basically what I suggested on Horn list - perhaps Horn should not try > to build trunk of everything, > but track compatibility issues between various revisions of > interdependent projects and build against > "newest version that works". > I think it would also be beneficial if it allowed me to specify that I > want to have my stack built with > Windsor 2.1.1, NHibernate x.y.z and MVCContrib some.official.release > and it should try to match them as required. > > I think Castle projects should release every 6 months, which I believe > is not too often. > As for multiple versions, I can't really see what is the problem here? > New functionality + other changes = new version. > We plan to drive the number of assemblies down. Less assemblies = less > things to manage = less confusion = less potential failure points. > > I also believe that documenting breaking changes (not just in public > API but also in behavior) should lower the barrier for other projects > to upgrade to vLast. > > Summing up - releasing reasonably often with well documented upgrade > path, should make it compelling for other projects to keep their > dependencies > up to date, and make them less likely to depend on unreleased version, > due to some neat functionality that does not get released for long > time. > > On 4 Mar, 15:41, 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]<castle-project-devel%[email protected]> > <castle-project-devel%[email protected]<castle-project-devel%[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]<castle-project-devel%[email protected]> > <castle-project-devel%[email protected]<castle-project-devel%[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]<castle-project-devel%[email protected]> > <castle-project-devel%[email protected]<castle-project-devel%[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]<castle-project-devel%[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.
