Breaking changes
In my last post, there were some comments from Olmo about breaking changes. Olmo is one of the best .NET developers I know, and he offered some very interesting ideas on how to handle them (for example, leveraging Roslyn to fix breaking changes).
Our position about breaking changes is that they are bad, very bad. We don’t want them, and we will try to avoid them as much as possible. We think it is a pain to work in a project and “fear” updating it because every time you do you have to fix your code to make it work again.
But, the reality is that breaking changes exist, and they will happen no matter how hard we try to avoid them. While we have used Wave in-house quite a lot, we are so used to it that we can miss issues that would be glaring for someone starting with it without prior knowledge. For example we have had a new person using it for building demos, and we got very interesting feedback from him. I am sure that when we release this situation will repeat itself a lot.
So, our idea so far in this front is to do something similar to how the XNA team performed their releases: try to avoid breaking changes in minor releases unless it’s a very important issue, but there will be major releases where we will put in all the minor changes we did not add to avoid breaking things. Not every major release will have to be like that, sometimes a release will just add support to a new platform, add new capabilities to the engine because of platforms evolution,… But we will do our best to not break things on minor updates so people can work on their projects confident that they will not have to lose time because of an upgrade.