If you've been paying attention to my recent posts, you probably noticed I have been thinking about ways we could improve the XNA Framework API. Which begs the question: how much is it possible to clean up an API while maintaining backward compatibility?
Backward compatibility is a terrifying topic for API designers. You just can't win.
If we make breaking changes, people are annoyed because their old code no longer works. And worse, this resets the supporting user community. Books, articles, samples, and engine code must be updated to the new version. This might be ok if it only happens every couple of years, but there is a limit to how often we can expect our community to deal with such a disruption.
But if we never make breaking changes, our product stagnates. Every design mistake and not fully thought out feature is forever cast in stone. Every random quirk of obsolete platforms must be inherited by all future platforms until the end of time. That isn't good for anyone.
In the past, XNA Game Studio has attempted a middle road. We made changes, knowing this could break some games, and required a recompile to move existing projects over to new framework versions, but we provided an upgrade wizard to help with this process, and tried to minimize API changes to make the upgrade as painless as possible. Multiple framework versions can be installed side by side, so old games continue to use the old framework while newer games use the new version. This allows us to make minor tweaks that we do not expect to break most games, knowing that if this causes problems for a few people, they will have a chance to fix their code while upgrading their projects (or of course they can choose to stick with the older version). We occasionally made bigger breaking changes in areas where we felt the benefit outweighed the cost, but every time we do this we see pain when customers try to use older tutorials with newer framework versions, then get confused because things have changed out from under them.
This compromise has worked ok for us so far, but it’s a confusing message: most stuff still works the same, except for some stuff that is different. Your game may or may not “just work” ™
We have learned a lot over the last couple of years. If I had a time machine, I would have many suggestions to send back to when we were originally designing this stuff! But from where we are now, it’s a tough choice. Do we leave things as they are, knowing our design has flaws, or do we fix problems and take the cost of a breaking change?