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.12 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.12 manually until the VS-side snap: Edit -> Schedule set under Artifacts -> disable toggle
AND
Remove the main to old release channel (17.12) default channel darc delete-default-channel --repo https://github.com/dotnet/msbuild --branch main --channel "VS 17.12"
Associate the main branch with the next release channel darc add-default-channel --channel "VS 17.12" --branch main --repo https://github.com/dotnet/msbuild
Check subscriptions for the forward-looking channel VS 17.13 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.12"
Update channel VS 17.12 to VS 17.13 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.12 is associated with the correct release branch darc get-default-channels --source-repo https://github.com/dotnet/msbuild --branch vs17.12
if it is not, darc add-default-channel --channel "VS 17.12" --branch vs17.12 --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.12 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.12 branch
Run the official build for vs17.12 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.12. If not, run manually ('Run pipeline' in upper right)
Run the official build for vs17.12 with no extra customization - OptProf should succeed now
Create 17.13 branding PR (in main) including public API baseline package version change: Branding for 17.13 #10703. In the file eng/Versions.props Update the VersionPrefix to 17.13 and PackageValidationBaselineVersion set to a latest internally available 17.12 preview version in the internal dnceng dotnet-tools feed. It might be needed to update CompatibilitySuppressions.xml files. See this documentation for more details. You can update CompatibilitySuppressions.xml files by running dotnet pack MSBuild.Dev.slnf /p:ApiCompatGenerateSuppressionFile=true.
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.12 and updates its version to 17.13, turn on / modify the VS insertion so that it flows from MSBuild main to VS main.
Update the requested SDK version for bootstrap folder (the BootstrapSdkVersion property in Versions.props) and buildToolCommand/_InitializeBuildToolCommand values in cibuild_bootstrapped_msbuild scripts if a fresh sdk was released (released runtimes and associated sdk versions can be checked here - https://dotnet.microsoft.com/download/visual-studio-sdks - make sure to always check the details of the appropriate targeted version of .NET for the matching latest version of SDK).
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.12 - channle start to publish in the next - VS 17.13 - channel) darc get-subscriptions --exact --target-repo https://github.com/dotnet/msbuild --target-branch main
MSBuild Release Checklist 17.12
At any time
17.11with the previous release version, for example17.917.12with the current release version, for example17.1017.13?with the next release version, for example17.11vs17.12branchVS 17.13?if it doesn't already existdarc add-channel --name "VS 17.13"At release time
vs17.12to VSmainin 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.12manually until the VS-side snap: Edit -> Schedule set under Artifacts -> disable toggleAND
mainto old release channel (17.12) default channeldarc delete-default-channel --repo https://github.com/dotnet/msbuild --branch main --channel "VS 17.12"mainbranch with the next release channeldarc add-default-channel --channel "VS 17.12" --branch main --repo https://github.com/dotnet/msbuildVS 17.13and update as necessary (for instance, SDK'smainbranch should usually be updated, whereas release branches often should not bedarc get-subscriptions --exact --source-repo https://github.com/dotnet/msbuild --channel "VS 17.12"darc update-subscription --id sdk_main_branch_idVS 17.12is associated with the correct release branchdarc get-default-channels --source-repo https://github.com/dotnet/msbuild --branch vs17.12if it is not,
darc add-default-channel --channel "VS 17.12" --branch vs17.12 --repo https://github.com/dotnet/msbuildvs17.12branche.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
mainin 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.jsoncfile to have the currently-in-servicing branches.SkipApplyOptimizationDatavariable in 'Advanced options' section of the 'Run pipeline' menu totrue) or alternatively with the latest Opt-Prof collected for the main branch (setOptional OptProfDrop Overrideto the drop path of the collected data, which could be found in the logs of the pipeline: Windows_NT -> Build -> search forOptimizationData).eng/Versions.propsUpdate theVersionPrefixto17.13andPackageValidationBaselineVersionset to a latest internally available 17.12 preview version in the internal dnceng dotnet-tools feed. It might be needed to updateCompatibilitySuppressions.xmlfiles. See this documentation for more details. You can updateCompatibilitySuppressions.xmlfiles by runningdotnet pack MSBuild.Dev.slnf /p:ApiCompatGenerateSuppressionFile=true.EnableReleaseOneLocBuildtotrueEnableReleaseOneLocBuildtofalse. Update the comment on the same line.EnableReleaseOneLocBuildto set up the merge conflict when this line will be updated in the release branch.InsertTargetBranchrel/d17.12.vs17.12: Add final branding VS17.12 #10697vs17.12branchBootstrapSdkVersionproperty in Versions.props) and buildToolCommand/_InitializeBuildToolCommand values in cibuild_bootstrapped_msbuild scripts if a fresh sdk was released (released runtimes and associated sdk versions can be checked here - https://dotnet.microsoft.com/download/visual-studio-sdks - make sure to always check the details of the appropriate targeted version of .NET for the matching latest version of SDK).ASAP On/After GA:
Timing based on the (Microsoft-internal) release schedule.
SUBMITTED: https://dev.azure.com/msft-skilling/Content/_workitems/edit/335681
nuget.configif it was added in theUpdate the PackageValidationBaselineVersionstepmainsubscriptions to the new channel (this can be done before or after release - depending on when the source repos from our previous - VS 17.12 - channle start to publish in the next - VS 17.13 - channel)darc get-subscriptions --exact --target-repo https://github.com/dotnet/msbuild --target-branch mainCreate Release from TagGH option (https://github.com/dotnet/msbuild/releases/new?tag=v17.9.3) - the release notes can be prepopulated (Generate Release Notes)