I like Krzysztof's idea of making smaller changes at once and more releases. This will allow users to easily move from 2.0 to 2.1 for example, with a very small list of breaking changes. Users are more likely migrate to newer versions as long as they don't come out every week :), and will provide much more feedback with a short release cycle.
This also makes planning and implementing releases much easier for the castle team. I think most people would agree that we can never again make as many breaking changes that RC3->2.0 has without making small releases in between. John, when you say you want to break the coupling that MonoRail has on other projects (e.g. AR and Windsor), are you saying they should be released in separate packages, because they are already all separate assemblies AFAIK. 2010/1/18 Krzysztof Koźmic (2) <[email protected]> > inline > > On 18 Sty, 13:05, John Simons <[email protected]> wrote: > > Now that Monorail v2 is out, is time to start thinking about what is > > next from Monorail v3. > > > > I've already created a uservoice for Monorail v3: > http://castle.uservoice.com/forums/38553-monorail-v3 > > > > But there is a list that I've started working on (this list is still > > growing and there will be more added), most of these are just by going > > through the source code of Monorail: > > > > - Need to break the coupling that Monorail currently has on other > > libs, at the moment Monorail is dependant on nearly all other Castle > > projects. I think to do this we need to enforce the same mechanism > > that Windsor uses by the use of facilities to extend the container. > > As long as we don't end up with tens of small assemblies with very few > types. > I'm all for breaking dependencies where it makes sense, but think > three time before creating yet another assembly for that. > > > > - MonoRail routing, well this is a grey area that currently is not > > totally complete, my view on this is lets just use the > > System.Web.Routing > This would be a major breaking change. And while my experience with > Monorail routing is none, does it not offer any advantages > over System.Web.Routing? OpenRasta for example, is a framework that > deliberately does not use SWR providing its own routing engine > While SWR has the advantage of being part of BCL and being very well > documented by books, blogs and MSDN, I would be very careful > when introducing such change. > > > > - javascript support, I think we are supporting too many different > > frameworks in this area, we are trying to maintain prototype, > > jquery,delicious,... > > I'd say due to immense popularity, we should put major emphasis on > JQuery > > > > > - Scaffolding, why is this tight to ActiveRecord? > > > > - How do we stay in business now with other offers like ASP.Net MVC, > > FubuMVC,... ? > > We release more often :) > > > > > - The whole code base needs a clean-up, remove obsolete code, ... > > Perhaps before v3.0 we should have a minor release first, with little > breaking changes > and mostly concentrated on clean up and polish? > > > > > The list is not finished, it is a work in progress. > > > > Cheers > > John > > -- > 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. > > > > -- Jono--
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.
