How to service a library

This document provides the steps that need to be followed after modifying a library in a servicing branch.

Servicing branches represent shipped versions of .NET. The branch naming convention varies by version:

• For .NET 8 and .NET 9: Branch names use the format release/X.0-staging. Examples:

  • release/9.0-staging
  • release/8.0-staging

• For .NET 10+: Branch names use the format release/X.0 (no -staging suffix). Examples:

  • release/10.0
  • release/11.0

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version. Keep in mind that we still need package authoring in .NET 8 and older versions.

Test your changes

Develop and test your change as normal. For packages, you may want to test them outside the repo infrastructure. To do so, execute the following steps:

1. From a clean copy of your branch, run build.cmd/sh libs -pack

2. Check in artifacts\bin\packages\Debug for the existence of your package, with the appropriate package version.

3. Try installing the built package in a test application, testing that your changes to the library are present & working as expected. To install your package add your local packages folder as a feed source in VS or your nuget.config and then add a PackageReference to the specific version of the package you built then try using the APIs.

Approval Process

All the servicing change must go through an approval process. You have two ways to submit your PR:

• By manually creating your PR using this template.

• Or by asking the bot to automatically create the servicing PR for you using a merged main PR as source. This method requires typing an AzDO backport command as a comment of your merged PR. The format depends on the target version:

  For .NET 8 and .NET 9 (use -staging suffix):

  • /backport to release/9.0-staging
  • /backport to release/8.0-staging

  For .NET 10+ (no -staging suffix):

  • /backport to release/10.0
  • /backport to release/11.0

For all cases, you must:

• Fill out the template of the PR description.
• Bring it to the attention of the engineering lead responsible for the area.
• If the fix is a product change, the area owner will:
  • Add the Servicing-consider label.
  • Ask the area owner to champion your PR in the .NET Tactics meeting to request merge approval.
  • If the change is approved, they will replace the Servicing-consider label by Servicing-approved and sign-off the PR.
• If the fix is a test-only or infra-only change, the area owner will:
  • Review the PR and sign-off if they approve it.
  • Add the Servicing-approved label.

The area owner can then merge the PR once the CI looks good (it's either green or the failures are investigated and determined to be unrelated to the PR).

Note: Applying the Servicing-approved label ensures the check-service-labels CI job passes, which is a mandatory requirement for merging a PR in a servicing branch.