>> 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/ 2010/3/3 Krzysztof Koźmic <[email protected]> > Paul, > > Castle itself does not rely on non-released version of any of its > dependencies (not that I'm aware of). > I admit no release for quite a long time made it the only option to use > Castle's trunk, but it's been > over 2 months (for some projects) since our v2.x rollout, which I think was > quite enough time for > projects depending on Castle stack to update their dependencies. > > What else do you think could Castle project do? > We are quite open about our release schedule: > http://castleproject.org/castle/projects.html > If there's anything we can do to improve the state of the matter we're > seriously interested. > > Krzysztof > > On 3/3/2010 10:39 PM, Paul Cowan wrote: > > i dont think the solution is 100% technical. relying on trunk builds is > part of the problem. > > i think all .net oss needs to somehow work with versions and not the the > trunk. > > at the moment i am trying to update my code to use asp.net 2.0. > > unfortunately this requires rebuilding mvccontrib which has a knock on of > building castle, nhibernate and rhino. > > everything uses different versions of everything else. > > it is a mess. > > On Mar 3, 2010 9:17 PM, "John Simons" <[email protected]> wrote: > > Paul, > > As you found out, this is not an easy task to solve on your own. > > What is Castle doing about it? > We have had a few discussions about this topic, and so far this is > what we came up with: > - Once a major project release is out eg v2.0.0 any future hotfixes/ > patches for this project release are version by incrementing the file > version eg v2.0.1 not the assembly version, see > > http://groups.google.com/group/castle-project-devel/browse_thread/thread/b34987a9980b215b/ae484513bac9ce5b > - Merge more assemblies together, you can read about it at > http://kozmic.pl/archive/2010/02/25/.net-oss-dependency-hell.aspx > > There are a couple of reasons it is so difficult to update Castle. > First not all projects have yet been released, eg > Castle.Facilities.AutomaticTransactionManagement, > Castle.Facilities.NHibernateIntegration, > Castle.Facilities.WcfIntegration. > Second the releases are autonomous and controlled by too many cooks!, > one way of solving this is to have a Release Manager, and this is > something we should consider, thoughts? > > I'm also of the opinion that the community has to change their ways of > always wanting to run the latest of the latest, do we really need to > run the latest of everything? > > Cheers > John > > > On Mar 4, 12:26 am, dagda1 <[email protected]> wrote: > > Hi Guys, > > > > First of all, I am a big fan of Castle and use many parts of the > > stack. Please see this as not a criticism but feedback. > > > > I am writing this to see if there is anything that can be done to > > alleviate what I and others are going through when it comes to > > updating a stack that heavily uses castle. > > > > I use: > > > > Castle.Core > > Castle.Components.Validator > > Castle.DynamicProxy2 > > Castle.Facilities.AutomaticTransactionManagement > > Castle.Facilities.NHibernateIntegration > > Castle.Facilities.WcfIntegration > > Castle.MicroKernel > > Castle.Services.Transaction > > Castle.Windsor > > > > What I am finding is that Castle.Facilities.WcfIntegration references > > a different version of windsor than other parts of the stack. > > > > There now appear to be 3 different versions of Castle.Core. > > > > I am finding it very difficult to keep track of what is getting on. > > > > Horn has been getting some good pull requests from some castle > > contributors and I really want to encourage this. > > > > If we can further use horn to help then we should. > > > > Can we do anymore to alleviate what is quickly turning into a maze of > > dependencies? > > > > Don't forget, this situation is intensified as other OSS projects use > > parts of castle. > > > > I had to pull the plug in updating my stack with Castle, Nhibernate, > > boo, MVCContrib and Rhino because I was about to throw my laptop > > through the window, > > > > The bits are just not fitting together. > > > > Paul > > -- > 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. > > > -- > 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.
