1.122.0 Endgame

[anthonykim1]

Endgame guide

Before Tuesday 6AM Zurich time

@team:

• Update endgame availability
• Test plan items created
• Milestone only has TPIs. All other issues need to be closed
• All closed issues in milestone labeled on-testplan, bug, or verification-needed
• Verification steps added to bug and verification-needed issues

Tuesday morning (Zurich)

@endgame-champ:

• Assign TPIs
  • Create TPI's for all verification needed bugs. Visit Testing and Verification on tools site, and generate groupings, then create TPIs. The TPI section below will update with all of the generated items.
• Pause automatic releases (this also ensures chat-pre-release isn't released) after 10am.
• Run the Start Endgame workflow
  • If you need to run these steps manually, see the Branching guide.

Tuesday morning (Redmond and Zurich)

@team:

• Test plan items. All TPIs must be finished by noon. This includes verification TPIs.
• Make sure your TPIs are being tested and ping folks if to confirm they will finish by noon.

Tuesday afternoon (Redmond and Zurich)

@team:

• Fix essential issues. Default to pushing to next iteration
• Release notes

Tuesday EOD Redmond time

@team:

• All issues including late fixes, are verified (query)
• Release notes written

@endgame-champ:

• Create new builds from release/<x.y> branch so we can finish verification. Not required to contain OSS Tool changes.
• Run the OSS Tool Workflow to update ThirdPartyNotices.txt for release. (detailed docs / manual fallback)
  • On Failure: an agentic workflow auto-dispatches to fix missing licenses. PR link is in the safe_outputs summary
    • Verify each new entry in cglicenses.json has the correct license + owner and merge the PR ([example])([OSS Tool] Fix OSS license errors in cglicenses.json #317212)), see docs for more details.
    • Trigger the OSS Tool Workflow again.
  • On Success: Review and merge the generated PRs.
    • Note: The cherry-pick workflow auto-generates cherry-pick PRs from release/* into main, those must also be merged. (example)

Wednesday by noon CET

@team:

• Fix essential issues. Default to pushing to next iteration
• Release notes

@endgame-champ:

• Generate "Thank you" section of the release notes in the vnext branch of the vscode-docs repo.
  • Acknowledge third-party pull requests in release notes.
  • Acknowledge issue trackers from the community (do the copy-paste variant) -
• Build and release insiders from release/<x.y>
• Build stable from release/<x.y> and release to MSFT folks
• Reenable automatic releases
  • A build is scheduled for 7:00 PM Zurich time (19:00 GMT+2); make sure automatic releases are reenabled before then so we get an Insiders build from main on Wednesday evening.

Wednesday afternoon/Thursday morning

• In extreme cases, accept candidate changes
  • Build stable from release/<x.y>. Do not bump the VS Code version.
  • Release stable to MSFT folks

Thursday

@endgame-champ:

• Stable starts rollout to everyone (start percentage: 20%, end time UTC: 6AM next Wednesday)
• Deploy vscode.dev (Branch release/x.y, Deployment Target prod, needs peer approval)
• Publish website
• Publish @types/vscode if you find type diffs after running the steps
• Create an official release
  • Create a tag (make sure you pull the release branch first): git tag <x.y.z>
  • Push the tag: git push origin <x.y.z>
  • Create a GitHub release: Open the GitHub tags, and click far right ... > Create Release. Use the version as title <x.y.z> and use the release link https://code.visualstudio.com/updates/v<x_y> for the description
• Close milestone
• Move all remaining issues to "On Deck"

[dmke]

So, are the release notes now intentionally just a list of PR titles grouped by date? That would be a huge drop in standards...

*1.122 Release Notes* *1.121 Release Notes*