I believe there are two sides to what backwards compatibility is. One is changing the names of a few namespaces, classes, or members. Basically, stuff that can be fixed by R# quickfixes, search&replaces, etc.
The other is, killing the support for creating a MockRepository and setting up mocks in the "old" way with Record/Verify. And I'm not just talking about being able to easily setting up whitelist-expectations. While this can be a no-go criteria in and of itself depending on the testing philosophy, there is an even bigger issue. Test suites that rely heavily on mocking usually are quite old. And for big projects, quite extensive. I'm talking about several thousand tests here. And that's several thousand tests that would have to be migrated, one by one, if one where to migrate to Rhino.Mocks 4.0. So, the actual question would be, will you provide a dotNet 4.0 and potentially a dotNet 5.0 release of Rhino.Mocks 3.6 for projects where the migration process would take several years? And yes, I know, we can always build our own Rhino.Mocks. Bottom line is, breaking backwards compatibility on a feature level will be a major blow for projects that have been a loyal follower of Rhino.Mocks since the early days of the project. Michael --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
