Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

March 2024 Endgame #208302

Closed
deepak1556 opened this issue Mar 21, 2024 · 1 comment
Closed

March 2024 Endgame #208302

deepak1556 opened this issue Mar 21, 2024 · 1 comment
Assignees
Labels
endgame-plan VS Code - Next release plan for endgame
Milestone

Comments

@deepak1556
Copy link
Collaborator

deepak1556 commented Mar 21, 2024

  • 03/22 Code freeze for the endgame
  • 03/28 Endgame done
  • 04/04 Expected release date (this may change)
Friday
  • Check that all queries in this issue use the current milestone @deepak1556
  • Run OSS tool @deepak1556
  • Update links in the Endgame notebooks to point to new milestone @deepak1556
  • 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 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 @deepak1556
  • 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. @deepak1556
    • 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.
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
    • 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.
  • 🔖Testing
  • 🔖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
  • 🔖Verification
  • Message team members as needed to add steps to verification-steps-needed issues @deepak1556
Wednesday
  • Make sure the insider build is green @deepak1556
  • 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
  • 🔖Verification needed
  • 🔖Verification
  • 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
Friday/Monday
Monday - Wednesday
  • 🔖milestone issues
  • 🔖candidate issues
  • Polish release notes redmond
  • 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
  • Manually release Insider @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)
@deepak1556 deepak1556 added the endgame-plan VS Code - Next release plan for endgame label Mar 21, 2024
@deepak1556 deepak1556 added this to the March 2024 milestone Mar 21, 2024
@deepak1556 deepak1556 pinned this issue Mar 21, 2024
@roblourens roblourens mentioned this issue Mar 23, 2024
15 tasks
@mbrevda
Copy link

mbrevda commented Apr 5, 2024

Thanks!

@bpasero bpasero unpinned this issue Apr 7, 2024
@microsoft microsoft locked and limited conversation to collaborators Jun 10, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
endgame-plan VS Code - Next release plan for endgame
Projects
None yet
Development

No branches or pull requests

4 participants
@mbrevda @deepak1556 @rzhao271 and others