docs/operations/Release.md
This document provides a guide on how to release a preview of YARP.
To keep track of the process, open a release checklist issue.
Ensure the eng/Versions.props file has the expected versions and pre-release labels. For a final release set PreReleaseVersionLabel to rtw.
See Branching:
First, identify the final build of the dotnet-yarp-official Azure Pipeline (on dnceng/internal). The final build will be the latest successful build in the relevant release/x branch. Use the "Branches" tab on Azure DevOps to help identify it. If the branch hasn't been mirrored yet (see dotnet-mirror-dnceng pipeline) and there are no outstanding changesets in the branch, the build of the corresponding commit from the main branch can be used.
Once you've identified that build, click in to the build details.
At this point, you can perform any validation that makes sense. At a minimum, we should validate that the sample can run with the candidate packages. You can download the final build using the "Artifacts" which can be accessed under "Related" in the header:
The packages can be accessed from the PackageArtifacts artifact:
dotnet nuget add source <directory> -n localWalk through the Getting Started instructions and update them in the release branch as needed.
Also validate any major new scenarios this release and their associated docs.
Once validation has been completed, it's time to release.
Go to the dotnet-yarp-release pipeline and select "Run Pipeline".
Under "Resources", select the pipeline run that you've validated artifacts for.
Triple-check the version numbers of the packages in the artifacts against whatever validation was done at this point.
Select "Run". Unless you're a release approver, you're done here!
The Azure Pipeline will send an email to all the release approvers asking one of them to approve the release.
Click "Review Manual Validation", or navigate to the release pipeline directly in Azure DevOps. You'll see that the stage is "Pending Approval"
Enter a comment such as "release for preview X" approve finalize the release. After approving, packages will be published automatically. It is possible to cancel the pipeline, but it might be too late. See "Troubleshooting" below.
The packages will be pushed and when the "NuGet.org" stage turns green, the packages are published!
Note: NuGet publishing is quick, but there is a background indexing process that can mean it will take up to several hours for packages to become available
Create and push a git tag for the commit associated with the final build (not necessarily the HEAD of the current release branch). See prior tags for the preferred format. Use a lightweight tag, not annotated.
git tag v1.0.0-previewX
Push the tag change to the upstream repo (not your fork)
git push upstream v1.0.0-previewX
Create a draft release at https://github.com/dotnet/yarp/releases using the new tag. See prior releases for the recommended content and format.
Publish the draft release notes. These should be referencing the latest docs, packages, etc..
It should be empty now. If it's not, move the outstanding issues to the next one.
David Fowler has a lot of twitter followers interested in YARP. Tweet a link to the release notes and let him retweet it.
This is to avoid accidental pushes to/deletions of the preview branch.
There should only be one preview branch on the repo after this point.
https://prod.******prod word to portal| Field | Value |
|---|---|
| Team Alias | dotnetrp |
| Business Group Name | Devdiv |
| Product Name | YARP |
| Version | <release version> |
| Production Type | dotNET |
| Release Type | <RC or Release> |
| Operating System(s) | Cross Platform |
| Product Language(s) | English |
| Release Date | <release date> |
| File Count | <rough number of files in repo> |
| Back Up Type | Code Repo(Git URL/AzureDevOps) |
| Repo URL | <link to the internal AzDo YARP repo> |
| OwnerAlias | dotnetrp |
| File Collection | Build Scripts, Help Utility Source Code, Source Code |
| Data Size | <rough total files size in MB> |
The pipeline is authenticated via a "Service Connection" in Azure DevOps. If there are authentication errors, it's likely the API key is invalid. Follow these steps to update the API key:
@microsoft.com address that has access to the dotnetframework organization.In the event you don't have access, contact [email protected] for guidance.
In the event you overpublish (publish a package that wasn't intended to be released), you should "unlist" the package on NuGet. It is not possible to delete packages on NuGet.org, by design, but you can remove them from search results. Users who reference the version you published directly will still be able to download it, but it won't show up in search queries or non-version-specific actions (like installing the latest).
@microsoft.com address that has access to the dotnetframework organization.NuGet.org has special criteria for all packages starting Microsoft.. If the package is rejected for not meeting one of those criteria, go to the NuGet @ Microsoft page for more information on required criteria and guidance for how to configure the package appropriately.