dotnet
Proposal to provide API Compat tools
Design doc for: https://github.com/dotnet/core/issues/5701 Contributes to: https://github.com/dotnet/core/issues/5700
Relates to: https://github.com/dotnet/roslyn-analyzers/issues/3901
cc: @terrajobst @danmoseley @ericstj @Anipik @sharwell @ViktorHofer @stephentoub
Feel free to loop in other people that might be interested on this.
I was wondering today whether I could reuse some of the tooling I know from dotnet repos in my own libraries. @ViktorHofer pointed me to this design.
I see many things I'd like in the design doc. This is how I imagine using them:
After adding something in csproj, dotnet build produces a text file that describes the public API and compares it with a text file that describes the previous API.
When they differ on my development machine, I get a warning during the build. When they differ in the CI build, it is an error.
When I think the changes are good, I can copy them over, and include them in the commit.
See also https://github.com/dotnet/roslyn-analyzers/issues/3047 for some places where the Roslyn PublicApiAnalyzer could have been extended.
I see many things I'd like in the design doc. This is how I imagine using them:
After adding something in csproj, dotnet build produces a text file that describes the public API and compares it with a text file that describes the previous API. When they differ on my development machine, I get a warning during the build. When they differ in the CI build, it is an error. When I think the changes are good, I can copy them over, and include them in the commit.
Thanks @tmds for your input and interest on this. I will push an updated doc after the feedback and your input and will describe more extensively the scenarios and how customers would use it.
See also dotnet/roslyn-analyzers#3047 for some places where the Roslyn PublicApiAnalyzer could have been extended.
Thanks, @drewnoakes, will make sure to include all of them in the list of rules. I believe most of them are already covered, but I need to confirm.
Adding [Obsolete] to a member, I think that should be configurable by excluding/including the attribute from the attributes list so that each customer can tweak about the attributes they care... maybe for a major release they want to obsolete some members and want to exclude that attribute from the errors in the compatibility checks from one release to the other.
