From 0e1e28d8d6d4fd753056193a46c4405648793e70 Mon Sep 17 00:00:00 2001 From: Billy Robert O'Neal III Date: Thu, 19 Oct 2023 16:29:28 -0700 Subject: [PATCH 1/2] More @data-queue feedback. --- docs/vcpkg_registry_release_process.md | 15 ++++++++++++--- docs/vcpkg_tool_release_process.md | 7 +++++-- 2 files changed, 17 insertions(+), 5 deletions(-) diff --git a/docs/vcpkg_registry_release_process.md b/docs/vcpkg_registry_release_process.md index 62603f0275..32350838dd 100644 --- a/docs/vcpkg_registry_release_process.md +++ b/docs/vcpkg_registry_release_process.md @@ -2,15 +2,24 @@ This document describes the acceptance criteria / process we use when doing a vcpkg registry release. +1. Make sure the contents of the repo have what you want to release. 1. Create a git tag for the release. -1. Submit a full CI rebuild for the tag. + ```console + >git fetch origin # Where origin is whichever remote points to microsoft/vcpkg + >git switch -d origin/master + >git tag 2023.10.19 # Replace this with the correct date of course :) + >git push origin 2023.10.19 + ``` +1. Submit a full CI rebuild ( https://dev.azure.com/vcpkg/public/_build?definitionId=29 ) for the tag. e.g. `refs/tags/2023.10.19` 1. Checkout the tag 1. Run vcpkg z-changelog `` > `path/to/results.md` -1. Create a new GitHub release in the registry repo. +1. Create a new GitHub release in the registry repo on the tag. 1. Run 'auto generate release notes' 1. Change `## New Contributors` to `#### New Contributors` 1. Copy the contents to the end of `path/to/results.md` (the `#### New Contributors` part should line up) 1. Change the link to the full rebuild. 1. Fill out the block about tool release changes. -1. After the full rebuild submission completes, change all the 'Building...'s to actual counts. +1. Change FROM and TO at the top to be the previous tag and the new one. +1. Copy `path/to/results.md` into the github release and publish it. (You can delete `path/to/results.md` now :)) +1. After the full rebuild submission completes, change all the 'Building...'s to actual counts in the release. 1. After a blog post for that release is authored, add a link to the blog post to the release. diff --git a/docs/vcpkg_tool_release_process.md b/docs/vcpkg_tool_release_process.md index 4fa870388d..ebec33327b 100644 --- a/docs/vcpkg_tool_release_process.md +++ b/docs/vcpkg_tool_release_process.md @@ -51,9 +51,12 @@ such as https://github.com/microsoft/vcpkg/pull/23757 1. Go to the root of the VS repo and run `init.cmd -CoreXTProfileName VSPartners` 1. Submit this as a change to the VS repo. Example: https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_git/VS/pullrequest/498110 Don't forget to attach the work item number from the previous step. -1. Smoke test the copy of vcpkg inserted into VS. See smoke test steps below. +1. Smoke test the copy of vcpkg inserted into VS. See smoke test steps below. The prototype copy is + at "CloudBuild - PR -> Extensions\VS Enterprise\Release Channel" as of 2023-10-19 but this UI + changes frequently. 1. (After all tests have passed, at the same time) Merge all 3 PRs, and change the github release in vcpkg-tool from "prerelease" to "release". (This automatically updates the aka.ms links) +1. Mark any `requires:vcpkg-tool-release` issues as fixed by the tool release. # Release Data Flow @@ -152,7 +155,7 @@ flowchart TD # Smoke Testing VS -1. Install the prototype version of VS with the vcpkg inserted. Ensure the native desktop workload is selected, and that vcpkg and cmake bits are installed. Don't forget about preinstall. +1. Install the prototype version of VS with the vcpkg inserted. Ensure the native desktop workload is selected, and that vcpkg and cmake bits are installed. Don't forget about preinstall. ( `\\vspreinstall\preinstall\preinstall.cmd` ? ) 1. Open a developer command prompt and run `vcpkg integrate install` (this step hopefully removed soon) * This also verifies that vcpkg installed into the developer command prompt correctly. 1. Create a new C++ console project. From 1689b9156df0ec6e9d031828b5eca4a21908a531 Mon Sep 17 00:00:00 2001 From: Billy Robert O'Neal III Date: Thu, 19 Oct 2023 17:08:28 -0700 Subject: [PATCH 2/2] Get rid of from/to --- docs/vcpkg_registry_release_process.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/vcpkg_registry_release_process.md b/docs/vcpkg_registry_release_process.md index 32350838dd..c0a02f7157 100644 --- a/docs/vcpkg_registry_release_process.md +++ b/docs/vcpkg_registry_release_process.md @@ -19,7 +19,6 @@ This document describes the acceptance criteria / process we use when doing a vc 1. Copy the contents to the end of `path/to/results.md` (the `#### New Contributors` part should line up) 1. Change the link to the full rebuild. 1. Fill out the block about tool release changes. -1. Change FROM and TO at the top to be the previous tag and the new one. 1. Copy `path/to/results.md` into the github release and publish it. (You can delete `path/to/results.md` now :)) 1. After the full rebuild submission completes, change all the 'Building...'s to actual counts in the release. 1. After a blog post for that release is authored, add a link to the blog post to the release.