I agree that killing backwards compatibility is a must. The current API is very overwhelming to newcomers which makes it very difficult to teach people what works with what.
I'm sure most new users will start learning by just playing to see how things work, which breaks down if they accidentally use syntax designed for another pattern. On Fri, Sep 4, 2009 at 5:39 AM, Ayende Rahien <[email protected]> wrote: > I think killing backwards compatibility is a must have. > > Is that what you mean? > > On Thu, Sep 3, 2009 at 10:36 PM, Shane C <[email protected]>wrote: > >> >> I think backwards compatibility is a must have. Presenting on and >> teaching Rhino Mocks to a new team has gotten silly because of how big >> the API has gotten. I would gladly stick with Rhino Mocks 3.6 where >> currently used and Rhino Mocks 4.0 for new stuff... >> >> On Sep 1, 10:19 am, Tim Barcz <[email protected]> wrote: >> > Do we need to kill backwards compatibility. I'm working on a >> patch/spike >> > where the class Fake is used which really just calls MockRepository >> under >> > the hood? >> > >> > Thoughts? >> > >> > >> > >> > On Tue, Sep 1, 2009 at 10:56 AM, Ayende Rahien <[email protected]> >> wrote: >> > > This is a blog post that would show up day after tomorrow, I am >> posting it >> > > here to get some traction in the mailing list before we make it really >> > > public. >> > >> > > Well, now that Rhino Mocks 3.6 is out of the way, we need to think >> about >> > > what the next version will look like. >> > >> > > Initially, I thought to match Rhino Mocks 4.0 to the .NET 4.0 release >> and >> > > support mocking dynamic variables, but while this is still on the >> planning >> > > board, I think that it is much more important to stop and take a look >> at >> > > where Rhino Mocks is now and where we would like it to be. >> > >> > > I started Rhino Mocks about 5 years ago, and the codebase has stood >> well in >> > > the test of time. There aren’t any nasty places and we can keep >> releasing >> > > new features with no major issues. >> > >> > > However, 5 years ago the community perception of mocking was different >> than >> > > what it is now. Rhino Mocks hasn’t really changed significantly since >> it 1.1 >> > > days, for that matter, you can take a code base using Rhino Mocks for >> .Net >> > > 1.1 and move it to Rhino Mocks 3.6 with no issues. >> > >> > > But one of the most frequent complaints that I have heard is that >> Rhino >> > > Mocks API has became too complex over the years, there are too many >> options >> > > and knobs that you can turn. I know that my own style of interaction >> testing >> > > has changed as well. >> > >> > > The current plan for Rhino Mocks 4.0 is that we will break backward >> > > compatibility in a big way. That means that we are going to >> drastically >> > > simplify everything in the framework. >> > >> > > We are still discussing this in the mailing list, but currently it >> looks >> > > like we will go with the following route: >> > >> > > - Kill the dynamic, strict, partial and stub terminology. No one >> cares. >> > > It is a fake. >> > > - Remove the record / playback API. The AAA method is much simpler. >> > > - Simplify mocking options, aiming at moving as much as possible >> from >> > > expectation style to assert style. >> > > - Keep as much of the current capabilities as we can. That means >> that >> > > if Rhino Mocks was able to support a scenario, it should still >> support it >> > > for the 4.0 version, hopefully in a simpler fashion. >> > >> > > The end result is putting Rhino Mocks on an API diet. I am looking for >> help >> > > in doing this, both in terms of suggested syntax and in terms of >> actual >> > > patches. >> > >> > > You are welcome to contribute… >> > >> > -- >> > Tim Barcz >> > Microsoft ASPInsiderhttp://timbarcz.devlicio.ushttp:// >> www.twitter.com/timbarcz >> >> > > > > -- Jono --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino.Mocks" 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/rhinomocks?hl=en -~----------~----~----~----~------~----~------~--~---
