[Package Validation] We should support excluding tfms when running the validation
See original GitHub issueIn dotnet/runtime we have been following a convention with our packages where we drop TFMs that are out of support from our packages. This results on a lot of errors that need to be suppressed because we are intentionally dropping these TFMs.
Also, when this happens, in baseline validation, if an asset is drop it will take another asset that is compatible for that TFM in the new package, i.e, if we had netcoreapp3.1 and netstandard2.0 asset, then we drop netcoreapp3.1, and now it will compare the netcoreapp3.1 asset from the baseline package vs the netstandard2.0 from the new version, resulting in a lot of errors as the API surface might be fairly different, so that comparison is not valuable in a lot of cases and it can become very noisy.
I suggest we add some support like an ItemGroup to specify ignored tfms for baseline validation, i.e:
<PackageValidationBaselineIgnoreTfm Include="netcoreapp3.1" />
Or we could introduce a flag to ignore out of support tfms and then we can use the list from the SDK for which tfms are out of support, i.e:
<PackageValidationBaselineIgnoreEolTfms>true</PackageValidationBaselineIgnoreEolTfms>
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:8 (5 by maintainers)
Top GitHub Comments
I guess that is fair. I probably chose my words incorrectly, I guess my thoughts were more that doing so is effectively breaking your previous package, whether that is common or not, and to me Package Validation’s layer purpose was more to be objective and find all breaking changes between two packages. That said, your point is valid that it is becoming more common to drop support for some frameworks, so I think it is fine to consider adding this extensibility point.
That could probably work, but I’m not sure I agree it is specific. Dropping older targets and replacing with new ones in major versions is pretty common.