Marked shipped API and set new PackageValidation version#5033
Marked shipped API and set new PackageValidation version#5033joperezr wants to merge 6 commits intomicrosoft:mainfrom
Conversation
joperezr
requested review from
ReubenBond,
eerhardt,
radical and
sebastienros
as code owners
ghost
added
the
needs-area-label
eerhardt
left a comment
eerhardt
left a comment
There was a problem hiding this comment.
The change looks good to go.
I do want to start a discussion on whether we do package validation on preview packages.
| <Description>Add support for provisioning AWS application resources and configuring the AWS SDK for .NET.</Description> | ||
| <!-- This package hasn't shipped stable, so package validation runs against previously shipped version of it. --> | ||
| <PackageValidationBaselineVersion>8.0.1-preview.8.24267.1</PackageValidationBaselineVersion> | ||
| <PackageValidationBaselineVersion>8.1.0-preview.1.24373.2</PackageValidationBaselineVersion> |
There was a problem hiding this comment.
I don't want to block the rest of this PR, but I think we shouldn't do package validation until we actually ship stable. (Or at least, don't do public API validation in the package validation)
The reasoning is that we are free to change the public APIs until the library ships stable. Doing package validation just gets in the way and confuses people when they try to change the APIs. For example, in #4950, I needed to disable validation because I was updating to the new Azure.AI.OpenAI dependency.
There was a problem hiding this comment.
Package validation doesn't only validate you haven't broken APIs against the previously shipped package, but it also does some checks within the package itself to make sure the APIs you are shipping and different TFMs you are shipping are consistent within the package. Right now this is probably not super valuable given most of our packages don't multitarget, but that will change soon. All this to say, I agree there is not a lot of benefit on running Baseline validation (the one that checks against a previously shipped package) but I wouldn't fully disable all validation.
Also, we could continue running baseline package validation, and just generate suppression files for the API changes (as opposed to disabling the validation all together). The advantage of that is that we could then realize when we are making a breaking change on a preview package, so that we can remember to mention something in the release notes for customers to upgrade.
There was a problem hiding this comment.
I needed to disable validation because I was updating to the new Azure.AI.OpenAI dependency.
Instead of disabling validation, you can alternatively just pass the property /p:GenerateCompatibilitySuppressionFile=true as indicated here in order to generate a suppression file.
|
This is now stale and has been superseded. closing. |
Pull request was closed
github-actions
Bot
added
area-integrations
2 participants
Now that 8.1 has shipped, this is marking all of the relevant APIs as shipped as well as enabling package validation on new packages and setting the right baseline version.
Microsoft Reviewers: Open in CodeFlow