I think we should try to _not_ split up the repositories, at least in the first time. If we start to have versioning conflicts, we can review it and split if necessary.
Cheers, Henry Conceição On Tue, Oct 28, 2008 at 7:41 PM, Markus Zywitza <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
