What is a breaking change?

While on my FrontLine trip I was surprised at the number of teams that produce a “shared library”.  That is team “A” is producing an assembly that other teams across the company (or outside the company) need to consume.   It was interesting to me as this is exactly what we do in building the .NET Framework and WinFX.   So when I got back to the office I set about trying to make sure our “best practices” for this sort of thing are published.  


One of the more valuable resources we use internally is a formal definition of what a “breaking change” is.  That is what are the rules team “A” should follow such that new builds of their library don’t break all their clients.  Some things are obvious “don’t remove any public methods” but some are subtle such as “don’t change return types of public methods”. 


Breaking Changes in a Managed World


Oh, and here is Kit’s intro to the doc

Comments (8)

  1. Andrew says:

    Are you really expecting someone to download an exe with that name lightheartedly?



  2. Frederik says:

    You might want to remove the commens from that Word file. It’s not really useful.

    As for downloading a file, I’d trust most things that come from dowload.microsoft.com and is digitally signed.

  3. What’s a breaking change … and what’s not?

  4. David Smith says:

    I think something that may impact how many breaking changes need to be made is the Interface Extractor that ships with VS2005.

    This tool is extremely useful, but I’m weary of the fact that developers may build their classes and extract interfaces without thinking much about what implications that may have later down the road.

    Then it may turn out that the interface may need to change later in the game. *breaking change alert*

    Ideally, we’d like to see interfaces published, and never touched again.

    Have you guys thought about the Interface Extractor functionality in VS2005 in the past, and its implications to the design process?

    It seems like worth-while enough oppritunity for risk to design process itself to address.

    P.S. I love the Interface Extrator. =D

  5. Matt says:

    "I was surprised at the number of teams" – One day you should come an visit and investment bank, you might then see the size and quantity of libraries that are reused within a single organisation

  6. Thogek says:

    BTW, *any* information — standards, best practices, advice, etc — that Microsoft might have for those of us who are getting started in the area of building common shared library code would be much appreciated.


Skip to main content