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
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 @deepak1556
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.
Redmond members commence testing the TPIs authored by Zurich members, enabling them to address any feedback on the following day.
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.
Confirm with team extension authors when to disable continuous insider builds (includes vscode.dev publishing). The default time is Thursday EOD (Redmond) @deepak1556
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
Remind the team that we want to verify as many issues as we can before branching on Thursday EOD (Redmond), and ping team members as needed to remind them to add steps to verification-steps-needed issues @deepak1556
By Thursday EOD (Redmond), branch from main and release @deepak1556
Disable the continuous release by toggling the continuous release button on the top-right corner of the Builds page
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)
Remind team extension authors to check if all release branch changes have been published to users. If not, they need to build and manually release a new prerelease version of their extension. @deepak1556
Build but don't release a stable build from release/<x.y> branch to ensure stable build is green @deepak1556
Bump up the version in package.json on main - @deepak1556
Create next milestone and ensure that it has a due date. The created milestone and its due date will be automatically synced across our repos. @deepak1556
Thursday
Only candidate issues are open and assigned to 🔖milestone
candidate fixes should be made for major bugs only - to be discussed in stand-up meeting and approved
Endgame champion / authors of candidate PRs should find testers to test merged candidates. VS Code candidates should be tested on newly released Insiders.
Satellite modules/npm packages ready, version updated, smoke tested
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. @deepak1556
Cherry-pick hand-picked and reviewed changes to release/<x.y>, and close open candidate issues that have already been merged to the release branch. @deepak1556
Build Insider from release/<x.y> (roughly on a daily basis) @deepak1556
Endgame champion / authors of candidate PRs should find testers to test merged candidates. VS Code candidates should be tested on newly released Insiders. team
Build but don't release stable for all platforms as new candidate issues come in @deepak1556
Documentation updated
Run scripts/test-documentation.sh|bat 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. @deepak1556
Coordinate the official release timing with team and more specifically, team extension authors (ex: Jupyter and Copilot rely on VS Code release) @deepak1556
Note: The Insiders build needs to be in the wild for 24 hours before we can enter the last phase of the endgame. @deepak1556
Wednesday/Thursday - Expected release day (this may change)
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 @deepak1556
Request approval from another team member at the necessary step to deploy the vscode.dev build. @deepak1556
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
Friday
verification-needed
oron-testplan
labelMonday
blocked
and status update comment in the issue.Tuesday
verification-steps-needed
issues @deepak1556Wednesday
insider
build is green @deepak1556insider
builds (includes vscode.dev publishing). The default time is Thursday EOD (Redmond) @deepak1556verification-steps-needed
issues @deepak1556main
and release @deepak1556release/<x.y>
release/*
as the VS Code Branch parameter (it's the default so you shouldn't have to change anything)main
is open for business and all issues on the current iteration are candidates and that the candidate release process is to be followed.stable
build from release/<x.y> branch to ensure stable build is green @deepak1556package.json
onmain
- @deepak1556Thursday
candidate
fixes should be made for major bugs only - to be discussed in stand-up meeting and approvedcandidate
PRs should find testers to test merged candidates. VS Code candidates should be tested on newly released Insiders.v<Major>_<Minor>.md
_ in this repo directoryFriday/Monday
Monday - Wednesday
release/<x.y>
, and close open candidate issues that have already been merged to the release branch. @deepak1556Insider
fromrelease/<x.y>
(roughly on a daily basis) @deepak1556Insider
@deepak1556candidate
PRs should find testers to test merged candidates. VS Code candidates should be tested on newly released Insiders. teamscripts/test-documentation.sh|bat
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. @deepak1556Wednesday/Thursday - Expected release day (this may change)
main
for all platforms @deepak1556release/x.y
for theprod
deployment target. Note that there are four deploy approvals needed - one for overall and one per each of the three service regions @deepak1556git 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 Exampleinsider
builds @deepak1556main
@deepak1556The text was updated successfully, but these errors were encountered: