MSBuild release process

This is a description of the steps required to release MSBuild. It is incomplete; when something not present here is discovered to be required it should be added.

Final branding/versioning

To produce packages without a -prerelease suffix, we need to specify <DotNetFinalVersionKind>release</DotNetFinalVersionKind> (see the Arcade versioning docs). This is ideally done on the same line as the version specification so that it causes a Git merge conflict when merging to the next release's branch. See #6902 for an example.

Run scripts/Stabilize-Release.ps1 to automate this process. The script modifies eng/Versions.props to add DotNetFinalVersionKind and change PreReleaseVersionLabel from preview to servicing. Use -DryRun to preview changes before applying them.

Public API

As of #7018, MSBuild uses a Roslyn analyzer to ensure compatibility with assemblies compiled against older versions of MSBuild. The workflow of the analyzer is:

The analyzer keeps the PublicAPI.Unshipped.txt files updated.
New API surface goes into PublicAPI.Unshipped.txt.
At release time, we must manually promote the Unshipped public API to Shipped.

That is a new step in our release process for each formal release (including patch releases if they change API surface).

Major version extra update steps

Update major version of VS in