question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[Package Validation] We should support excluding tfms when running the validation

See original GitHub issue

In 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>

cc: @ericstj @joperezr

Issue Analytics

  • State:open
  • Created 2 years ago
  • Reactions:1
  • Comments:8 (5 by maintainers)

github_iconTop GitHub Comments

1reaction
joperezrcommented, May 26, 2022

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.

1reaction
dotMortencommented, May 26, 2022

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Package Validation - .NET Blog
Package Validation tooling will allow library developers to validate that their packages are consistent and well-formed. It involves validating ...
Read more >
SSIS Package Validation in the Catalog - Tim Mitchell
In this post, SSIS guru Tim Mitchell demonstrates SSIS package validation, showing how this feature can help identify errors before package ...
Read more >
Using the full training set (no validation) - Part 1 (2018)
Hi, As suggested by Jeremy Howard, when there is no validation set we can use approx 20% of the training set for validation....
Read more >
Package Validation Suite | Package Manager UI website
The Package Validation Suite requires the Package Manager UI extension mechanism, which is available from version ... The validation tests will get run....
Read more >
Minutes of the Federal Aviation Administration (FAA) ...
Marcus Lowther [Metron]: Comparisons to TFMS, are there any validation docs that we can reference to get a baseline for an FMS flight...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found