Generate diff artifact as part of es.net build script.
Type="Deleted" or Type="Modified" is presentType="Modified" on typesWhat's the desired outcome? If you are after a feedback loop to inform you about potential breaking API changes to type signatures then check out this pattern
https://github.com/reactiveui/ReactiveUI/tree/master/src/ReactiveUI.Tests/API
ApiApprovalTests.cs is executed per TFM, generates the diff and compares against blessed aka ApiApprovalTests.Testing.[TFM].approved.txt which is checked into git. As this is a unit test it breaks the build upon incoming PR's if the surface changes. It's not 100% perfect because behavior of an API isn't checked _but_ over at ReactiveUI we have found that it greatly reduces the burden of reviewing PR's and is an excellent safe guard.
ps. this also means the history of the API surface for the entire library is version controlled in a text file that's super easy to git history.
We use: https://github.com/nullean/AssemblyDiffer which handles TFM's as well.
It allows us to compare the current build assemblies with a version on nuget.
The trouble is we need to feed that tool previous Nuget versions manually since depending on what branch we are we need a different version to compare against
| branch | version | action |
|---------|----------|---------
| 5.x | latest 5.xon nuget.org | fail if breaking |
| 6.x | latest 6.x on nuget.org | fail if breaking |
| 7.x | latest 7.x on nuget.org | fail if breaking |
| master | latest on nuget.org | break all the things! |
The version resolution requires investigating how Nuget.Client and its N auxialiary packages stitch together, things were a tad easier when it was OData. We currently use the v2 OData endpoints and but they've been deprecated for years now.
Closing this as this change has now been made in 6.x and 7.x. For example
> build skipdocs skiptests
> build diff "nuget|NEST.JsonNetSerializer|6.6.0|netstandard2.0 directory|../../build/output/Nest.JsonNetSerializer/netstandard2.0"
This will
We can aim to make this even easier to run in future so that you can just call something like
build diff "nuget|6.x|netstandard2.0"
to compare local compiled with the latest 6.x released version.
@russcam I think we should leave this open until it's part of build release <VERSION>. Right now we can call it easily from the command line but it's quite a mental chore composing the right arguments and finding the previous version to diff against
Also build canary which the PR's run, ideally these fail when diff target introduces a breaking change (depending on the branch)
Could we open two new issues for those, and keep the scope of this to including as a build target?
I'm down that with that :+1:
Most helpful comment
We use: https://github.com/nullean/AssemblyDiffer which handles TFM's as well.
It allows us to compare the current build assemblies with a version on nuget.
The trouble is we need to feed that tool previous Nuget versions manually since depending on what branch we are we need a different version to compare against
| branch | version | action |
|---------|----------|---------
|
5.x| latest5.xon nuget.org | fail if breaking ||
6.x| latest6.xon nuget.org | fail if breaking ||
7.x| latest7.xon nuget.org | fail if breaking ||
master| latest on nuget.org | break all the things! |The version resolution requires investigating how
Nuget.Clientand its N auxialiary packages stitch together, things were a tad easier when it was OData. We currently use the v2 OData endpoints and but they've been deprecated for years now.