You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the release is being cut more than a few days before the VS-side snap, do these two steps. Otherwise check them off.
Modify the VS insertion so that it flows from MSBuild vs17.11 to VS mainin the MSBuild-release-branch release definition. Alternatively, if the release being cut no more than couple of weeks, disable the scheduled releases and create releases from vs17.11 manually until the VS-side snap: Edit -> Schedule set under Artifacts -> disable toggle
AND
Remove the main to old release channel (17.11) default channel darc delete-default-channel --repo https://github.com/dotnet/msbuild --branch main --channel "VS 17.11"
Associate the main branch with the next release channel darc add-default-channel --channel "VS 17.11" --branch main --repo https://github.com/dotnet/msbuild
Check subscriptions for the forward-looking channel VS 17.12 and update as necessary (for instance, SDK's main branch should usually be updated, whereas release branches often should not be darc get-subscriptions --exact --source-repo https://github.com/dotnet/msbuild --channel "VS 17.11"
Update channel VS 17.11 to VS 17.12 for the sdk main subscription and any others from the previous step darc update-subscription --id sdk_main_branch_id
Ensure that the current release channel VS 17.11 is associated with the correct release branch darc get-default-channels --source-repo https://github.com/dotnet/msbuild --branch vs17.11
if it is not, darc add-default-channel --channel "VS 17.11" --branch vs17.11 --repo https://github.com/dotnet/msbuild
If the branch was created before the fork: fast-forward merge the correct commit (the one that is currently inserted to VS main) to the vs17.11 branch
e.g.: git push upstream 2e6f2ff7ea311214255b6b2ca5cc0554fba1b345:refs/heads/vs17.10 (This is for the case where we create the branch too early and want it to be based actually on a different commit. If you waited until a good point in time with main in a clean state, just branch off and you are done. The branch should point to a good, recent spot, so the final-branding PR goes in on top of the right set of commits.)
Update the branch merge flow in .config/git-merge-flow-config.jsonc file to have the currently-in-servicing branches.
Fix OptProf data flow for the new vs17.11 branch
Run the official build for vs17.11 without OptProf (set SkipApplyOptimizationData variable in 'Advanced options' section of the 'Run pipeline' menu to true) or alternatively with the latest Opt-Prof collected for the main branch (set Optional OptProfDrop Override to the drop path of the collected data, which could be found in the logs of the pipeline: Windows_NT -> Build -> search for OptimizationData).
Check that the OptProf data collection pipeline run is triggered for vs17.11. If not, run manually ('Run pipeline' in upper right)
Run the official build for vs17.11 with no extra customization - OptProf should succeed now
Create 17.12 branding PR (in main) including public API baseline package version change: Version 17.12 #10268. In the file eng/Versions.props Update the VersionPrefix to 17.12 and PackageValidationBaselineVersion set to a latest internally available 17.11 preview version in the internal dnceng dotnet-tools feed. It might be needed to update CompatibilitySuppressions.xml files.
Disable 17.10 localization - by setting EnableReleaseOneLocBuild to false. Update the comment on the same line.
Merge 17.12 branding PR
Create and merge a PR in main to update a localization version comment in setting EnableReleaseOneLocBuild to set up the merge conflict when this line will be updated in the release branch.
When VS main snaps to 17.11 and updates its version to 17.12, turn on / modify the VS insertion so that it flows from MSBuild main to VS main.
Remove the temporarily added build feed from nuget.config if it was added in the Update the PackageValidationBaselineVersion step
Update main subscriptions to the new channel (this can be done before or after release - depending on when the source repos from our previous - VS 17.11 - channle start to publish in the next - VS 17.12 - channel) darc get-subscriptions --exact --target-repo https://github.com/dotnet/msbuild --target-branch main
MSBuild Release Checklist 17.11
At any time
vs17.11
branchVS 17.12
if it doesn't already existdarc add-channel --name "VS 17.12"
At release time
vs17.11
to VSmain
in the MSBuild-release-branch release definition. Alternatively, if the release being cut no more than couple of weeks, disable the scheduled releases and create releases fromvs17.11
manually until the VS-side snap: Edit -> Schedule set under Artifacts -> disable toggleAND
main
to old release channel (17.11) default channeldarc delete-default-channel --repo https://github.com/dotnet/msbuild --branch main --channel "VS 17.11"
main
branch with the next release channeldarc add-default-channel --channel "VS 17.11" --branch main --repo https://github.com/dotnet/msbuild
VS 17.12
and update as necessary (for instance, SDK'smain
branch should usually be updated, whereas release branches often should not bedarc get-subscriptions --exact --source-repo https://github.com/dotnet/msbuild --channel "VS 17.11"
darc update-subscription --id sdk_main_branch_id
VS 17.11
is associated with the correct release branchdarc get-default-channels --source-repo https://github.com/dotnet/msbuild --branch vs17.11
if it is not,
darc add-default-channel --channel "VS 17.11" --branch vs17.11 --repo https://github.com/dotnet/msbuild
vs17.11
branche.g.:
git push upstream 2e6f2ff7ea311214255b6b2ca5cc0554fba1b345:refs/heads/vs17.10
(This is for the case where we create the branch too early and want it to be based actually on a different commit. If you waited until a good point in time with
main
in a clean state, just branch off and you are done. The branch should point to a good, recent spot, so the final-branding PR goes in on top of the right set of commits.).config/git-merge-flow-config.jsonc
file to have the currently-in-servicing branches.SkipApplyOptimizationData
variable in 'Advanced options' section of the 'Run pipeline' menu totrue
) or alternatively with the latest Opt-Prof collected for the main branch (setOptional OptProfDrop Override
to the drop path of the collected data, which could be found in the logs of the pipeline: Windows_NT -> Build -> search forOptimizationData
).eng/Versions.props
Update theVersionPrefix
to17.12
andPackageValidationBaselineVersion
set to a latest internally available 17.11 preview version in the internal dnceng dotnet-tools feed. It might be needed to updateCompatibilitySuppressions.xml
files.EnableReleaseOneLocBuild
totrue
EnableReleaseOneLocBuild
tofalse
. Update the comment on the same line.EnableReleaseOneLocBuild
to set up the merge conflict when this line will be updated in the release branch.InsertTargetBranch
rel/d17.11
.vs17.11
: Final branding for 17.11 #10270vs17.11
branchASAP On/After GA:
Timing based on the (Microsoft-internal) release schedule.
nuget.config
if it was added in theUpdate the PackageValidationBaselineVersion
stepmain
subscriptions to the new channel (this can be done before or after release - depending on when the source repos from our previous - VS 17.11 - channle start to publish in the next - VS 17.12 - channel)darc get-subscriptions --exact --target-repo https://github.com/dotnet/msbuild --target-branch main
Create Release from Tag
GH option (https://github.com/dotnet/msbuild/releases/new?tag=v17.9.3) - the release notes can be prepopulated (Generate Release Notes
)The text was updated successfully, but these errors were encountered: