OpenSource library- Breaking changes
Part 1 |
|
Part 2 |
|
Part 3 |
|
Part 4 |
|
Part 5 |
|
Part 6 |
|
Part 7 |
Following guidance from https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/breaking-changes
Nr |
Recomandation |
AOP Roslyn |
1 |
DO think about how your library will be used. What effect will breaking changes have on applications and libraries that use it? |
|
2 |
DO minimize breaking changes when developing a low-level .NET library. |
|
3 |
CONSIDER publishing a major rewrite of a library as a new NuGet package. |
|
4 |
CONSIDER leaving new features off by default, if they affect existing users, and let developers opt in to the feature with a setting. |
|
5 |
DO NOT change an assembly name. |
|
6 |
DO NOT add, remove, or change the strong naming key. |
|
7 |
CONSIDER using abstract base classes instead of interfaces. |
|
8 |
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. |
|
9 |
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
Leave a Reply