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.11
with the previous release version, for example17.9
17.12
with the current release version, for example17.10
17.13?
with the next release version, for example17.11
vs17.12
branchVS 17.13?
if it doesn't already existdarc add-channel --name "VS 17.13"
At release time
vs17.12
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.12
manually until the VS-side snap: Edit -> Schedule set under Artifacts -> disable toggleAND
main
to old release channel (17.12) default channeldarc delete-default-channel --repo https://github.com/dotnet/msbuild --branch main --channel "VS 17.12"
main
branch with the next release channeldarc add-default-channel --channel "VS 17.12" --branch main --repo https://github.com/dotnet/msbuild
VS 17.13
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.12"
darc update-subscription --id sdk_main_branch_id
VS 17.12
is associated with the correct release branchdarc 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
vs17.12
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.13
andPackageValidationBaselineVersion
set to a latest internally available 17.12 preview version in the internal dnceng dotnet-tools feed. It might be needed to updateCompatibilitySuppressions.xml
files. See this documentation for more details. You can updateCompatibilitySuppressions.xml
files by runningdotnet pack MSBuild.Dev.slnf /p:ApiCompatGenerateSuppressionFile=true
.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.12
.vs17.12
: Add final branding VS17.12 #10697vs17.12
branchBootstrapSdkVersion
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).ASAP On/After GA:
Timing based on the (Microsoft-internal) release schedule.
SUBMITTED: https://dev.azure.com/msft-skilling/Content/_workitems/edit/335681
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.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
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: