The context of deployment obviously matters a lot. If the software is packaged and installed entirely at customer sites with little to no integration with other software, than what you’re saying may be true. On the other hand, in the case where the software is run as a service supporting multiple clients, integrated with 3rd party software, then backwards compatibility can ease many versioning pains.

Thanks for your comments.

Changes that break backward compatibility should be reserved for the next major version of the software.

Any customer who wants the next major version of your software should be running both the current and the new major versions in production in parallel.

When the customer decides that the new major version is stable and capable enough of fully replacing the current major version, the current major version can be retired.

That’s something me and Greg have been going back and forth on for quite a while, looking to formalize the different components patterns, but we haven’t completed that yet.

When we do, I’m sure you’ll hear of it.

Thanks for the link – looks interesting.

What do you think of event sourcing the reporting schemas and message handler assignments?

I just blogged about that: http://adventuresinagile.blogspot.com/2009/09/rewind-button-for-your-application.html

I’m afraid I haven’t come across any good books on this topic yet.

Ah – the post disappeared. Fixed.
Thanks.