[x] Create test plan items following the template here by 6pm PT
[x] 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 @dbaeumer
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.
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.
:loudspeaker: Continuous insider builds are now disabled.
[ ] 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 @dbaeumer
[ ] 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. @dbaeumer
Thursday/Friday - Depending on @dbaeumer timezone
[ ] By Thursday EOD (Redmond) or Friday BOD (Zurich), branch from main and release @dbaeumer
[ ] Branch following repositories to release/<x.y>
[ ] vscode
[ ] vscode-distro
[ ] vscode-dev
[ ] 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)
[ ] Announce main is open for business and all issues on the current iteration are candidates and that the candidate release process is to be followed.
[ ] Build and manually release Insider from release/<x.y> branch for Code
[ ] Build and manually release Insider from release/<x.y> branch for vscode.dev (if there were vscode.dev candidates)
[ ] Announce in #release@dbaeumer
:loudspeaker: 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 @dbaeumer
[ ] Bump up the version in package.json on main - @dbaeumer
[ ] 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. @dbaeumer
Friday
[ ] Only candidate issues are open and assigned to 🔖milestone
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 (CSEClientPatching@microsoft.com) know of that fact. Please cc Monacotools on this email as the client patching team has asked us to do so. @dbaeumer
[ ] 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. @dbaeumer
[ ] Build but don't release stable for all platforms as new candidate issues come in @dbaeumer
[ ] Coordinate the official release timing with team and more specifically, team extension authors (ex: Jupyter and Copilot rely on VS Code release) @dbaeumer
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. @dbaeumer
Wednesday/Thursday - Expected release day (this may change)
[ ] Build stable for all platforms @dbaeumer
[ ] Build but don't release an insider build based on main for all platforms @dbaeumer
[ ] Release stable from builds page no later than 11am PT @dbaeumer
[ ] Trigger the vscode.dev Deploy pipeline for release/x.y for the prod deployment target. Note that there are four deploy approvals needed - one for overall and one per each of the three service regions @dbaeumer
[ ] Request approval from another team member at the necessary step to deploy the vscode.dev build. @dbaeumer
[ ] Create an official release @dbaeumer
[ ] 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 @chrisdias
[ ] Create and publish next release notes placeholder @ntrogh
iwangbowen
commented
2 days ago
Sometimes we have slight adjustments to the endgame plan to account for local holidays. Please update your endgame plan accordingly.
Monday
verification-neededoron-testplanlabelTuesday
blockedand status update comment in the issue.Wednesday
verification-steps-neededissues @dbaeumerThursday
insiderbuild is green @dbaeumerinsiderbuilds and announce in#release@dbaeumerverification-steps-neededissues @dbaeumerscripts/test-documentation.sh|batafter 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 thecolorsection invscode-known-variables.jsoncan be moved under theotherssection of that file. @dbaeumerThursday/Friday - Depending on @dbaeumer timezone
mainand release @dbaeumerrelease/<x.y>release/*as the VS Code Branch parameter (it's the default so you shouldn't have to change anything)mainis open for business and all issues on the current iteration are candidates and that the candidate release process is to be followed.#release@dbaeumerstablebuild from release/<x.y> branch to ensure stable build is green @dbaeumerpackage.jsononmain- @dbaeumermicrosoft/vscoderepo and ensure that it has a due date. The created milestone and its due date will be automatically synced across our repos. @dbaeumerFriday
candidateissues (major bugs only)release/<x.y>Monday
Monday - Wednesday
candidateissues (major bugs only)release/<x.y>Wednesday/Thursday - Expected release day (this may change)
mainfor all platforms @dbaeumerrelease/x.yfor theproddeployment target. Note that there are four deploy approvals needed - one for overall and one per each of the three service regions @dbaeumergit tag <x.y.z>git push origin <x.y.z>... > 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 Exampleinsiderbuilds @dbaeumermain@dbaeumer