Skip to content

August 2025 Endgame #264311

New issue
New issue
Closed
Closed
August 2025 Endgame#264311
Assignees
sandy081osortega
Labels
endgame-planVS Code - Next release plan for endgame
Milestone
August 2025
@sandy081

Description

@sandy081
sandy081
opened on Sep 1, 2025

Sometimes we have slight adjustments to the endgame plan to account for local holidays. Please update your endgame plan accordingly.

  • September 1, 2025 Code freeze for the endgame
  • September 2, 2025 Endgame starts
  • September 5, 2025 Endgame done
  • September 10, 2025 Expected release date (this may change)
Monday
  • Pin endgame issue on GitHub @sandy081
  • Assess public holidays and adjust the endgame plan accordingly to ensure that announcements are made when the team can respond to them. @sandy081
  • Run OSS tool @sandy081
  • Update links in the Endgame notebooks to point to new milestone @sandy081
  • Code freeze at 9pm CET, PRs should no longer be accepted to ensure a green build
  • Ensure we have a green build on all platforms at 9pm CET
  • 🔖Ensure all closed feature-requests either have a verification-needed or on-testplan label
  • Create test plan items following the template here by 6pm PT
    • Remind the team that TPIs should be written so that anyone can test. If this is not feasible, then TPI authors should assign specific testers @sandy081
  • Update your availability for testing here - https://tools.code.visualstudio.com/team-manifest team
    • Double check N/A testers. @sandy081
    • Remind team that in the event of sickness or overload with TPIs, to inform the endgame champ ASAP so items can be reassigned
  • Remind team to go through their fixed issues for the milestone and update repro steps for issues which require more detailed instructions.
  • Set up the endgame retrospective to discuss process improvement
  • Set up a standup meeting for Friday to discuss candidates
Tuesday
  • Test plan items assigned (using https://tools.code.visualstudio.com/test-plan-items)
    • Run the tool multiple times to balance load if test items come in later and assignments are already made
    • Assigned to you
  • Test build starts at 7am CET
  • Test plan ready by 8am CET
  • Remind the team about the priorities
    • Tuesday should be dedicated exclusively to testing activities. Our goal is to ensure the completion of all Test Plan Items (TPIs) and subsequently proceed with the verification phase. Fixes or commits should be refrained from unless there are exceptional circumstances such as blocked TPIs or build-related issues. On Tuesday Redmond EOD, only blocked TPIs should remain open with a corresponding label blocked and status update comment in the issue.
  • Testing and Verification
Wednesday
  • 🔖Testing
    • These remaining TPIs should be the ones that are currently blocked. Discuss during the standup and redistribute assignments based on the TPI owner and the test coverage. For instance, if a TPI is owned by a member from Zurich and has not undergone sufficient testing, it will be reassigned to one of the Zurich team members.
  • Remind team members to triage issues found in testing and assign major issues that they intend to fix to the current milestone. Remind team to move out or close other open issues/PRs on the milestone that they do not intend to fix this milestone.
  • 🔖Verification needed
  • Fixing (self-assigned, milestone assigned)
  • 🔖Verification
  • Message team members as needed to add steps to verification-steps-needed issues @sandy081
Thursday
  • Make sure the insider build is green @sandy081
  • Fixing (self-assigned, milestone assigned)
    • Increased scrutiny sets in due to testing being completed. Fixes pose a much higher risk
    • Move open issues/PRs to the next month that can be deferred
  • Emphasize to the team that we want to verify as many issues as we can before the branching time, and ping team members as needed to remind them to add steps to verification-steps-needed issues @sandy081
  • 🔖Verification needed
  • 🔖Verification
  • Fix any issues regarding new undocumented colors. @sandy081
    • In the vscode-docs repo, merge the main branch into vnext
    • Run scripts/test-documentation.sh|bat after compiling the vscode repo, and fix any issues regarding new undocumented colors. Changes made to the vscode-docs repository must be merged to the main branch of that repository for the script to acknowledge them. False positives within the color section in vscode-known-variables.json can be moved under the others section of that file.
  • Ensure Copilot Chat CG is happy @sandy081
  • Ensure the Copilot Chat CI / Build is green @sandy081
  • Test upgrading from last month's VS Code and release Copilot Chat extension to this month's. @sandy081
Thursday/Friday - Depending on @sandy081 timezone
  • Make sure the insider build is green @sandy081
  • By Thursday EOD (Redmond) or Friday BOD (Zurich), branch from main and release @sandy081
    • Run OSS tool once again from main to ensure picking up any dependency license changes @sandy081
    • Disable continuous insider builds and announce in #release
    • Branch following repositories to release/<x.y>.
      • vscode
      • vscode-distro
      • vscode-dev
    • Bump up the version in package.json on main & run npm i to bump package-lock.json as well. @sandy081
    • Branch vscode-copilot-chat @sandy081
      • Create new release branch with format release/<version> where <version> is 0.X from package.json
      • Bump the minor version number in main to the next monthly version (bump X in 0.X.0), run npm install to update package-lock.json
    • Announce main is open for business, and all issues on the current iteration should now be candidates that need to follow the candidate release process.
    • Localization: Run Update VS Code Branch build with release/* as the VS Code Branch parameter (it's the default so you shouldn't have to change anything)
    • Trigger the ⭐️ VS Code pipeline from release/<x.y>, with the insiders Quality and enable Release build if successful.
    • Trigger the [vscode.dev] 🚀 Deploy pipeline from release/<x.y>, with the insiders Deployment Target.
    • Announce in #release @sandy081

      📢 Extension authors ensure all release branch changes have been published to users, manually building and releasing if necessary.

  • Build but don't release a stable build from release/<x.y> branch to ensure stable build is green @sandy081
  • Create next milestone on microsoft/vscode repo and ensure that it has a due date. The created milestone and its due date will be automatically synced across our repos. @sandy081
Friday
Monday
  • Polish release notes @ntrogh
  • Schedule an endgame restrospective with with @sandy081, endgame buddy, and next @sandy081 for this week. Retrospective template
  • Decide whether a Patch Tuesday release will happen:
    • Check the internal iteration plan for scheduled security issues (MSRCs) to determine if a Patch Tuesday release is needed.
    • If no Patch Tuesday release is planned, use the Patch Tuesday E-Mail Template to let the Updates team ([email protected]) know of that fact. Please cc Monacotools on this email as the client patching team has asked us to do so. @sandy081
    • Otherwise, if a Patch Tuesday release is necessary, start off a Patch Tuesday Release plan @sandy081
  • Remind the team: if they are going to be OOF for more than five days during the next iteration, assign someone to look out for critical issues in their feature areas and fix them if necessary. This helps with bug identification and fixing for recovery releases. @sandy081
Monday - Wednesday

Note: The Insiders build needs to be in the wild for 24 hours before we can enter the last phase of the endgame, though the sanity testing step alone can happen earlier if there are no new candidates. @sandy081

Wednesday/Thursday - Expected release day (this may change)
  • Build stable for all platforms @sandy081
  • Manually run the Copilot Chat stable pipeline against the release/<version> branch @sandy081
    • Enable Publish Extension, you do not need an approval to build the VSIX.
    • DO NOT ask for approval for the extension publish step yet. This step should only be done 1 hour before VS Code core releases (see release plan for Wednesday/Thursday for more info).
    • If the simulation tests fail due to cache changes on main, you will need to specify running with the release branch of the cache. You can do this under "Resources" when scheduling the pipeline.
  • Sanity test Copilot Chat Stable
    • VS Code RC @benibenj
      • anyOS
    • Codespaces Web using Insiders (Until CAPI supports Codespaces tokens natively. See #6095 for more information) @dbaeumer
      • We use Insiders because we cannot use Codespaces Web on core builds that are not released yet (even with custom query parameters in the URL).
  • Keep an eye out for any changes in the core RC (via candidates) that may require Copilot Chat to sanity test again on a new core stable build. @sandy081
  • Sanity Testing VS Code Stable
    • Windows 64 bit @hediet
      • System Installer
      • User Installer
      • Archive
      • Server
      • CLI
    • Windows ARM64 @hediet
      • System Installer
      • User Installer
      • Archive
      • Server
      • CLI
    • macOS Intel @deepak1556
      • Archive
      • Universal Archive
      • Server
      • CLI
    • macOS ARM64 @aiday-mar
      • Archive
      • Universal Archive
      • Server
      • CLI
    • Linux x64 @aeschli
      • Archive
      • DEB
      • RPM
      • Snap
    • Linux Server and CLI @alexr00 @deepak1556 (can be tested from any OS with Docker)
      • x64
      • ARM32
      • ARM64
      • x64 Alpine
      • ARM64 Alpine
  • Release Copilot Chat 1 HOUR before VS Code releases @sandy081
    • Approve the Publish stage of the last Copilot Chat stable pipeline that's successfully sanity tested.
      • Note that there are two steps that need approval to publish the extension to the marketplace.
    • In vscode-copilot-chat, bump the engines.vscode version on the main branch to point to the next version. For example, from 1.81.0 to 1.82.0. This ensures pre-release only runs on the latest insiders, which is necessary for proposed API development. Does not require the insiders to be released, only to be available on the builds page.
    • In vscode-copilot-chat, run npm install to update package-lock.json
  • Manually release a new pre-release from main by running the pre-release pipeline.
  • Publish website @ntrogh @sandy081
  • Release stable from builds page no later than 11am PT @sandy081
  • Trigger the [vscode.dev] 🚀 Deploy pipeline from release/x.y, with the prod Deployment Target. ⚠️ Peer approval needed. @sandy081
    • Request approval from another team member at the necessary step to deploy the vscode.dev build. @sandy081
  • Create an official release @sandy081
    • 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 correct title and description from our release notes. Also change the relative links for the key highlight list items to absolute links Example
  • X announcement @pierceboggan
  • Create and publish next release notes placeholder @ntrogh
  • Enable Continuous Release in the Insiders builds page @sandy081
  • Release the latest Insiders build from the Insiders builds page @sandy081
  • Trigger the [vscode.dev] 🚀 Deploy pipeline from main, with the insiders Deployment Target. @sandy081
  • Publish @types/vscode if you find type diffs after running the steps @sandy081
  • Close the milestone on GitHub @sandy081

Metadata

Metadata

Assignees

Labels

endgame-planVS Code - Next release plan for endgame

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions