.NET and Compatibility: Breaking Changes in a Managed World [Kit George]

.NET and Compatibility: Breaking Changes in a Managed World [Kit George]

  • Comments 1

Have you ever wondered how we define a breaking change? The document titled 'breaking changes in a managed world', available from the BCL Website formalizes the definitions worth discussion around breaking changes. Importantly, because nothing in this space is ever black or white, one of the key terms used in the document is 'acceptable change'. When reviewing breaking changes, the .NET team addresses all contentious issues on their merit. So even if an item is listed as 'breaking' or 'not breaking', a specific instance of an issue may or may not be allowed, based on investigation of the specific effects.

The intent of this document is to help formalize the definitions in the space, and help people understand the scope of changes which can affect their application. Code examples for changes are included with the download.

Note all: I do appreciate any feedback you have on this: what's missing, whether it's useful, etc. I intend for this to be aliving document, so I will be making updates. Ping me directly at kitg@microsoft.com with any feedback.

 

  • Wow. 49 pages of concentrated content - this is really great. I must compliment you. It's a well-written document.

    1. I wish it was exposed as an executable AND a web-interface of some sort; at least the BreakingChanges.doc, not neccessarily all the CS code. I don't expect people to download exes.

    2. Perhaps add a Visual Studio 2003/2005 Solution with all of the internal projects added, for ease-of-use. Just so people can run the projects without hitting the command-line.


    3. I'd like to see you more formally define a 'breaking change'. To me, a breaking change is something that alters expected results. And on that note...


    Performance changes as a breaking change:

    Most of your assumptions seem very straight-forward. But "3.2 - The performance of an operation should not be relied upon by clients. " The FUNCTIONALITY shouldn't change, a agree. But if you're changing sometihng from O(n) to O(n^2), then I would consider that a breaking change.

    Consider a consumer of an assembly that runs a function in a loop. Changing the O-time of the consumed function will provoke a serious change in the consuming assembly. (Especially in UI apps)

    In performance-critical applications, I would consider a substantial decrease in performance a breaking change. And so I'd put that in your 'Unacceptable Behavior Changes' section (5)


    4. It seems like this entire 'breaking change' discussion conflicts generally with the concept of Service Orientation. Isn't this what interfaces are for? Shouldn't breaking changes not exist? Just different interfaces? Emphasizing 'deprecate and add' =D You may want to touch on the interaction between design changes, and SOA, I know I'd appreciate it.
Page 1 of 1 (1 items)