Release 17.12

[maridematte]

MSBuild Release Checklist 17.12

At any time

• Create a new issue to track the release checklist, with this checklist copied into the issue.
  • Replace 17.11 with the previous release version, for example 17.9
  • Replace 17.12 with the current release version, for example 17.10
  • Replace 17.13? with the next release version, for example 17.11
• Create vs17.12 branch
• Create darc channel for VS 17.13? if it doesn't already exist
  darc add-channel --name "VS 17.13"
• Ping internal "First Responders" Teams channel to get the new channel made available as a promotion target (e.g. Make "VS 17.6" darc channel promotionable arcade#12150): {{URL_OF_CHANNEL_PROMOTION_PR}}

At release time

• 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 main 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 from vs17.12 manually until the VS-side snap: Edit -> Schedule set under Artifacts -> disable toggle
    AND
  • Disable automated run of the MSBuild-main-branch release definition (because our 17.13 builds don't have a place to go in VS yet)
• 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: {{URL_OF_NEXT_VERSION_BRANDING_PR}}. 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 17.12 localization ticket: https://aka.ms/ceChangeLocConfig (requesting to switch localization from {{PREVIOUS_RELEASE_VERSION}} to 17.12): {{URL_OF_LOCALIZATION_TICKET}}
• Enable 17.12 localization - by setting EnableReleaseOneLocBuild to true
• Disable {{PREVIOUS_RELEASE_VERSION}} localization - by setting EnableReleaseOneLocBuild to false. Update the comment on the same line.
• Merge 17.13 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.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 release-branch insertion release definition to have InsertTargetBranch rel/d17.12.
• Turn the release pipeline back on.
• Prepare final branding PR for vs17.12: {{URL_OF_FINAL_BRANDING_PR}}
• Merge final branding to vs17.12 branch
• Update perfstar MSBuild insertions configuration: example PR: {{URL_OF_PERFSTAR_PR}}
• Note down the build (will be helpful for requesting nuget packages publishing): {{URL_OF_BUILD}}
• Get M2 or QB approval as necessary per the VS schedule
• Merge to VS (babysit the automatically generated VS insertion PR https://devdiv.visualstudio.com/DevDiv/_git/VS/pullrequests for the MSBuild commit noted in above step): {{URL_OF_VS_INSERTION}}
• Update the PackageValidationBaselineVersion to the latest released version (17.12.0) - this might require temporary addition of the build artifacts feed as the new version is not yet added to the official feeds (this is post release). This can trigger a high severity CG error (https://eng.ms/docs/cloud-ai-platform/devdiv/one-engineering-system-1es/1es-docs/secure-supply-chain/how-to-securely-configure-package-source-files) - however it should be fine to keep this temporary feed untill the release.
• 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).

ASAP On/After GA:

Timing based on the (Microsoft-internal) release schedule.

• Push packages to nuget.org (not currently automated, contact dnceng - search "Publish MSBuild 17.6 to NuGet.org" email subject for template).
• Publish docs: submit reference request at https://aka.ms/publishondocs
  • Click on the link labeled Request – Reference Publishing
  • You can use existing ticket as a reference
• 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
• Create the 17.12 release
  • Create tag (can be done upfront)

  git checkout <commit noted above>
  git tag v17.12.3
  git push upstream v17.12.3
  

  • Create Release in Github with 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)