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…