Open
Description
- 4/25 Code freeze for the endgame
- 4/28 Endgame starts
- 5/2 Endgame done
- 5/7 Expected release date (this may change)
Friday
- Pin endgame issue on GitHub @lszomoru
- Run OSS tool @lszomoru
- Update links in the Endgame notebooks to point to new milestone @lszomoru
- Code freeze at 5pm PT, PRs should no longer be accepted to ensure a green build
- Ensure we have a green build on all platforms at 5pm PT
- 🔖Ensure all closed feature-requests either have a
verification-needed
oron-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 @lszomoru
- Update your availability for testing here - https://tools.code.visualstudio.com/team-manifest team
- Update availability of testers in vacation (Check OOF section in the Internal Backlog Plan). Double check N/A testers. @lszomoru
- 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
- Schedule an endgame restrospective with @lszomoru, endgame buddy, and next @lszomoru for late debt week
- Create the endgame retrospective tracking issue
- Set up a standup meeting for Friday to discuss candidates
Monday
- 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
- Monday 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.
- Monday 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
- Testing and Verification
- 🔖Testing
- 🔖Verification of Bugs Reported by me
- 🔖Verification needed
- 🔖Verification (If verification needed is finished)
Tuesday
- 🔖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 @lszomoru
Wednesday
- Make sure the
insider
build is green @lszomoru - 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 @lszomoru - 🔖Verification needed
- 🔖Verification
- 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 thecolor
section invscode-known-variables.json
can be moved under theothers
section of that file. @lszomoru
Thursday
Friday
- Disable continuous
insider
builds and announce in#release
@lszomoru📢 Continuous
insider
builds are now disabled. - Friday BOD (Zurich), branch from
main
and release @lszomoru- 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. - Trigger the ⭐️ VS Code pipeline from
release/<x.y>
, with theinsiders
Quality and enableRelease build if successful
. - Trigger the [vscode.dev] 🚀 Deploy pipeline from
release/<x.y>
, with theinsiders
Deployment Target. - Announce in
#release
@lszomoru📢 Extension authors ensure all release branch changes have been published to users, manually building and releasing if necessary.
- Branch following repositories to
- Build but don't release a
stable
build from release/<x.y> branch to ensure stable build is green @lszomoru - Bump up the version in
package.json
onmain
& runnpm i
to bumppackage-lock.json
as well. @lszomoru - 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. @lszomoru
Friday
- Only candidate issues are open and assigned to 🔖milestone
- All issues 🔖verified
- All open PRs on the milestone 🔖merged or deferred
- Fix
candidate
issues (major bugs only)- Discuss and get approval in stand up
- Review and merge into
release/<x.y>
- Queue new auto-published insiders build as candidates are merged @lszomoru
- Author of candidate PR should find verifier
- Satellite modules/npm packages ready, version updated, smoke tested
- yo generator @aeschli
- js-debug @connor4312
- Debug Adapter Protocol @connor4312
- vscode-debugadapter-node @connor4312
- vscode-test-web @aeschli
- All release notes updated
- release notes are collected in a file named _
v<Major>_<Minor>.md
_ in this repo directory - Release notes screen recording guidance: https://microsoft-my.sharepoint.com/:p:/p/buhollan/Ecg_j89jzlVGtfqWGy7SQBEB_OsuLPZ65jjKRVlo_OdlgA
- release notes are collected in a file named _
- Documentation added or updated
- Acknowledge third-party pull requests in release notes. @lszomoru
- Acknowledge issue trackers from the community @chrmarti
- When done fixing/verifying and there are changes since last build at the end of day PT
Monday
- Polish release notes @ntrogh
- Schedule an endgame restrospective with with @lszomoru, endgame buddy, and next @lszomoru 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. @lszomoru
- Otherwise, if a Patch Tuesday release is necessary, start off a Patch Tuesday Release plan @lszomoru
- 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. @lszomoru
Monday - Wednesday
- 🔖milestone issues
- 🔖candidate issues
- Polish release notes redmond
- Fix
candidate
issues (major bugs only)- Discuss and get approval in stand up
- Review and merge into
release/<x.y>
- Queue new auto-published insiders build as candidates are merged @lszomoru
- Author of candidate PR should find verifier
- Build but don't release stable for all platforms as new candidate issues come in @lszomoru
- Coordinate the official release timing with team and more specifically, team extension authors (ex: Jupyter and Copilot rely on VS Code release) @lszomoru
- Run OSS tool once again from
release/<x.y>
to ensure picking up any dependency license changes @lszomoru
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. @lszomoru
Wednesday/Thursday - Expected release day (this may change)
- Build stable for all platforms @lszomoru
- Sanity Testing
- Windows 64 bit owner
- System Installer
- User Installer
- Archive
- Server
- CLI
- Windows ARM64 owner
- System Installer
- User Installer
- Archive
- Server
- CLI
- macOS Intel owner
- Archive
- Universal Archive
- Server
- CLI
- macOS ARM64 owner
- Archive
- Universal Archive
- Server
- CLI
- Linux x64 owner
- Archive
- DEB
- RPM
- Snap
- Linux Server and CLI owner (can be tested from any OS with Docker)
- x64
- ARM32
- ARM64
- x64 Alpine
- ARM64 Alpine
- Windows 64 bit owner
- Publish website @ntrogh @lszomoru
- Release stable from builds page no later than 11am PT @lszomoru
- Trigger the [vscode.dev] 🚀 Deploy pipeline from
release/x.y
, with theprod
Deployment Target.⚠️ Peer approval needed. @lszomoru- Request approval from another team member at the necessary step to deploy the vscode.dev build. @lszomoru
- Create an official release @lszomoru
- 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
- Create a tag (make sure you pull the release branch first):
- X announcement @chrisdias
- Create and publish next release notes placeholder @ntrogh
- Enable Continuous Release in the Insiders builds page @lszomoru
- Release the latest Insiders build from the Insiders builds page @lszomoru
- Trigger the [vscode.dev] 🚀 Deploy pipeline from
main
, with theinsiders
Deployment Target. @lszomoru - Inform extension endgame champs (copilot-chat) that a
insider
build for the next version is being published. They can then update the engine field. @lszomoru - Publish @types/vscode @lszomoru
- Close the milestone on GitHub @lszomoru