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.
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…)
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?