Article does not describe how to deliberately accept a breaking change

[bitbonk]

While the article describes how to circumvent a breaking change it does not talk about how to deliberately accept a breaking change. When I work von V2 of the package I decide to make breaking changes. How do I pack the nuget package without errors once I made the required breaking changes. With Microsoft.CodeAnalysis.PublicApiAnalyzers I would have added the API to PublicAPI.Unshipped.txt how do I do the same thing here?

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: ed723ea8-3645-7a48-3b30-858a6cbe976d
• Version Independent ID: c8d7765b-7332-b8e2-673d-77a32156294a
• Content: Baseline Package Validator - .NET
• Content Source: docs/fundamentals/package-validation/baseline-version-validator.md
• Product: dotnet-fundamentals
• GitHub Login: @dotnet-bot
• Microsoft Alias: dotnetcontent

[gewarren]

@ericstj Who can help with this question?

[bitbonk]

I did some more digging an I am assuming the way to do this is to suppress particular errors using a CompatibitySupressions.xml file as explained here.

Once you have released v2, you delete that file and everything starts over again.

I still think it would be good if this article goes through the full cycle that includes releasing a next version that will include deliberate breaking changes.

[ericstj]

@bitbonk is correct - you can use suppression files. @ViktorHofer should we update our docs to make the lifecylce of suppressions more clear?

[ViktorHofer]

Yes we should. Adding a lifecycle section makes perfect sense. @bitbonk do you want to help us update the documentation? Feel free to send a PR in which we can then collaborate on the content and exact wording.

[bitbonk]

@ViktorHofer I tried my best, see #36954.