OpenSource library- Breaking changes

Part 1

Implement Open-source library guidance

Part 2

OpenSource library – Cross-platform targeting

Part 3

OpenSource library-Dependencies

Part 4

OpenSource library- Source Link

Part 5

OpenSource library-versioning

Part 6

OpenSource library- Breaking changes

Part 7

OpenSource library- conclusion

Following guidance from



AOP Roslyn


DO think about how your library will be used. What effect will breaking changes have on applications and libraries that use it?


DO minimize breaking changes when developing a low-level .NET library.


CONSIDER publishing a major rewrite of a library as a new NuGet package.


CONSIDER leaving new features off by default, if they affect existing users, and let developers opt in to the feature with a setting.


DO NOT change an assembly name.


DO NOT add, remove, or change the strong naming key.


CONSIDER using abstract base classes instead of interfaces.


CONSIDER placing the ObsoleteAttribute on types and members that you intend to remove. The attribute should have instructions for updating code to no longer use the obsolete API.


CONSIDER keeping types and methods with the ObsoleteAttribute indefinitely in low and middle-level libraries.

Unfortunately, AOP Roslyn is not in the stage of breaking changes. But I have had another library, Exporter, and I have had made  3:  CONSIDER publishing a major rewrite of a library as a new NuGet package