Agreed. But I still prefer to split up repos. Castle.Core (with Components) and DP should released first, so that all projects can reference released libraries.
-Markus 2008/10/28 hammett <[EMAIL PROTECTED]> > > I share the concerns. But our current model of working - preventing a > whole release because one or two projects arent ready yet - has proved > unsuccessful, and damaged our reputation. > > > On Tue, Oct 28, 2008 at 2:27 PM, Markus Zywitza > <[EMAIL PROTECTED]> wrote: > > I hope we don't shoot our feet with this: > > > > How to make sure that all projects play along together well? What if AR > 1.0 > > uses a different DP than MR 1.0 since as a user I'd expect MR 1.0 working > > together with AR 1.0. > > The best approach would be splitting up the repos and using svn:externals > to > > released versions of inner-castle dependencies. This however robs us of > > making ad-hoc changes to those dependencies. > > Other way round, if the infrastructure keeps the same, how can I develop > on > > AR1.1 without affecting MR 1.0 development? I'll have to branch it to > make > > breaking changes without forcing MR to use 1.1 trunk. > > > > If there is a solution to that problem, all s fine. > > > > And BTW: If no else comes out to play, I volunteer for AR lead. > > > > -Markus > > > > > > 2008/10/28 hammett <[EMAIL PROTECTED]> > >> > >> Sure. Inlines. > >> > >> > Is everything staying in its place in the current repo or is it going > to > >> > split there as well? > >> > >> I'm not sure. For now I think would be simpler to keep things as they > are > >> now. > >> > >> > What projects is the split following? I assume (am I missing any?): > >> > >> All top level projects, and packaging/grouping the others: > >> - MonoRail > >> - ActiveRecord > >> - Windsor > >> - Components/Services > >> - Facilities > >> - DynamicProxy > >> > >> > MonoRail (are the different engines splitting off?) > >> > >> I dont think so. > >> > >> > Have any project leads been selected yet? > >> > >> Nope. They need to step in. > >> > >> > Will there be new mailing lists? > >> > >> Nope. > >> > >> > Will there be changes on the build system and in the wiki to make this > >> > clear? > >> > >> There might be, but I'm not planning to have something soon. > >> > >> > Does this mean the Castle Project is becoming the Castle Group (ala > the > >> > Apache group)? > >> > >> It always meant to be that. It's always been an umbrella. Til some > >> point it was manageable to release everything together. But now we > >> lack the resources to continue to do so. > >> > >> > >> > If so, will there be a path for project inclusion to share branding > (for > >> > example Rhino Mocks could be branded as a part of the Castle Group, > >> > meaning the developers share design philosophies and intentions, and > >> > perhaps that the projects share some developers)? > >> > >> I think we can have an incubation process. > >> > >> > What can we do to help find clear paths to releases for the projects > >> > that aren't nearly ready? > >> > >> Which project isn't nearly ready? > >> > >> > >> -- > >> Cheers, > >> hammett > >> http://hammett.castleproject.org/ > >> > >> > > > > > > > > > > > > > -- > Cheers, > hammett > http://hammett.castleproject.org/ > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
