I suggest you ...

Take into account existing tests before removing things

The Isuses log shows items that are going to be removed for release 3.5. While Rhino Mocks takes backwards compatibility a bit too far there is something to be said for stability in code that tests rely on. If every release or two of Moq I have to refactor a lot of tests there is no way I'm going to be able to continue using it.

2 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    anonymous shared this idea  ·   ·  Admin →
    under review  ·  Adminkzu (Admin, moq) responded  · 

    We’re working hard to keep backs compat, by basically hiding old/legacy API members and keeping compilation intact.

    We do remove members after 2 major versions, so you have to refactor as needed. That said, the intermediate version (the one containing the obsolete and warnings) helps you to see what you should be using instead.

    At the end of the day, if a given version of Moq does everything you need, you have no reason to upgrade to an incompatible version (which wouldn’t happen more than once a year, approx). I just pushed a couple breaking changes to 4.0 as that’s the next major release post-3.0.

    Keeping legacy APIs for 2 major versions gives you plenty of time to refactor or consider NOT to upgrade. We want to support new Moq scenarios without confusing new users with legacy APIs that are no longer in use.

    Would you prefer that we keep those APIs hidden while fully functional so that you don’t have to change anything? (new code will not see the legacy members…)

    1 comment

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • andreister commented  · 

        Some just things become obsolete and then prevent you from introducing new improvements, because they'd just stop to compile.

        IMHO, Moq is doing amazingly hard work for backwards compatibility.

        Perhaps, the question is how can the guys mitigate the breaking changes, in cases where it's not possible to keep the stuff intact?

        I, for one, would suggest a converting wizard then. Thoughts?

      Feedback and Knowledge Base