We can keep a single repo, yet have a separate "libs" folder for each project, so AR 1.1 will use a specific build of DP2. (actually afaik, AR depends on DP through NH and not directly, and at present, NH does not directly depend on DP2 ...)
So I say acoid YAGNI, and if we'd ever need to outgrow into separate repos we can always do this when wee need. we'd need separate bulids of course (per project) and separate installers/wizards And I'm putting myself up for MR lead. would have gone for Windsor but I'm much more fluent with MR. On Tue, Oct 28, 2008 at 11:49 PM, Henry Conceição <[EMAIL PROTECTED] > wrote: > > 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/ > >> > >> > > > > > > > > > > > > > -- Ken Egozi. http://www.kenegozi.com/blog http://www.musicglue.com http://www.castleproject.org http://www.gotfriends.co.il --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
