October 2022 Endgame

[rebornix]

• 10//24 Code freeze for the endgame
• 10/28 Endgame done
• 11/02 Expected release date (this may change)

Monday

• Check that all queries in this issue use the current milestone @rebornix
• Run OSS tool @rebornix
• Update links in the Endgame notebooks to point to new milestone @rebornix
• Code freeze at 5pm PT
• Ensure we have a green build on all platforms at 5pm PT
• 🔖All closed feature-requests either have a verification-needed or on-testplan label
• Create test plan items following the template here by 6pm PT
• Update your availability for testing here - https://vscode-tools.azurewebsites.net/team-manifest team
  • Update availability of testers in vacation. Double check N/A testers. @rebornix

Tuesday

• Test plan items assigned (using https://vscode-tools.azurewebsites.net/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
• 🔖Testing
• 🔖Verification needed

Wednesday

• 🔖Testing
• Remind team members to assign issues that they intend to fix to the current milestone
• Fixing (self-assigned, milestone assigned)
• 🔖Verification needed

Thursday

• Fixing (self-assigned, milestone assigned, no need for PR or review)
  • Increased scrutiny sets in due to testing being completed. Fixes pose a much higher risk
  • Move issues to the next month that can be deferred
• 🔖Verification needed
• 🔖Verification

Friday

• Build a stable build to ensure stable build is green @rebornix
• Pause scheduled insider builds @rebornix
• Satellite modules/npm packages ready, version updated, smoke tested
  • yo generator @aeschli
  • js-debug @connor4312
  • Debug Adapter Protocol @connor4312
  • vscode-debugadapter-node @roblourens
  • Mock Debug @roblourens
  • custom data for html/css @aeschli
• Only candidate issues are open and assigned to 🔖milestone
• All issues 🔖verified
• All open PRs on the milestone 🔖merged or deferred
• Branch code to release/<x.y> after all expected fixes are in (latest 5PM PST) @rebornix
• Branch distro to release/<x.y> after all expected fixes are in (latest 5PM PST) @rebornix
• Branch vscode.dev to release/<x.y> after all expected fixes are in (latest 5PM PST) owner
• 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) @rebornix
• Announce main is open for business @rebornix
• Fixing (PR + review required once branched - major bugs only - to be discussed in stand-up meeting, labeled as candidate)
• All release notes updated
  • release notes are collected in a file named v<Major>_<Minor>.md in this repo directory
  • @aeschli
  • @alexdima
  • @alexr00
  • @andreamah
  • @bpasero
  • @chrmarti
  • @connor4312
  • @dbaeumer
  • @deepak1556
  • @egamma
  • @hediet
  • @isidorn
  • @joaomoreno
  • @joyceerhl
  • @jrieken
  • @kieferrm
  • @lramos15
  • @lszomoru
  • @meganrogge
  • @mjbvz
  • @rebornix
  • @roblourens
  • @rzhao271
  • @sandy081
  • @sbatten
  • @TylerLeonhardt
  • @Tyriar
  • @weinand
• Acknowledge pull requests in release notes. We acknowledge PRs from outside the team. We have improved the tooling so that the @rebornix can generate the pull request acknowledgment for all repositories at once. @rebornix
  • debug-adapter-protocol, inno-updater, jsonc-parser, language-server-protocol, lsif-node, vscode, vscode-codicons, vscode-css-languageservice, vscode-debugadapter-node, vscode-dev-containers, vscode-docs, vscode-emmet-helper, vscode-eslint, vscode-extension-samples, vscode-generator-code, vscode-hexeditor, vscode-html-languageservice, vscode-js-debug, vscode-js-debug-companion, vscode-js-profile-visualizer, vscode-jshint, vscode-json-languageservice, vscode-languageserver-node, vscode-livepreview, vscode-loader, vscode-lsif-extension, vscode-node-debug, vscode-node-debug2, vscode-pull-request-github, vscode-recipes, vscode-references-view, vscode-textmate, vscode-vsce
• Acknowledge issue trackers from the community @chrmarti
• Add notable fixes to the release notes all
• When done fixing/verifying and there are changes since last build at the end of day PT
  • Build and manually release Insider from release/<x.y> @rebornix

Friday/Monday

• Polish release notes redmond
• Fixing (only critical bugs - no string changes)

Monday - Wednesday

• 🔖milestone issues
• 🔖candidate issues
• Polish release notes redmond
• Cherry-pick hand-picked and reviewed changes to release/<x.y> @rebornix
• Build Insider from release/<x.y> @rebornix
• Manually release Insider @rebornix
• Build stable for all platforms as new candidate issues come in @rebornix
• Documentation updated
  • @aeschli
  • @alexdima
  • @alexr00
  • @andreamah
  • @bpasero
  • @chrmarti
  • @connor4312
  • @dbaeumer
  • @deepak1556
  • @egamma
  • @hediet
  • @isidorn
  • @joaomoreno
  • @joyceerhl
  • @jrieken
  • @kieferrm
  • @lramos15
  • @lszomoru
  • @meganrogge
  • @mjbvz
  • @rebornix
  • @roblourens
  • @rzhao271
  • @sandy081
  • @sbatten
  • @TylerLeonhardt
  • @Tyriar
  • @weinand
• Run scripts/test-documentation.sh|bat and add file or fix issues if there are new colors that are not documented. @rebornix

Note: The Insiders build needs to be in the wild for 24 hours before we can enter the last phase of the endgame. @rebornix

Wednesday/Thursday - Expected release day (this may change)

• Build stable for all platforms @rebornix
• Sanity check of installable bits (server instructions)
  • Windows 32 bit
    • signed installer 32-bit @mjbvz
    • signed user installer 32-bit @mjbvz
    • zip 32-bit @roblourens
    • server 32-bit @roblourens
  • Windows 64 bit @roblourens
    • signed installer 64-bit
    • signed user installer 64-bit
    • zip 64-bit
    • server 64-bit
  • Windows ARM64 @sbatten
    • signed installer ARM64
    • signed user installer ARM64
    • zip ARM64
  • macOS
    • Intel + Universal @roblourens
    • Apple Silicon + Universal @kieferrm
  • Linux x64
    • deb @rebornix
    • rpm owner
    • archives @rebornix
    • snap (sudo snap install --classic --dangerous <file>.snap) owner
  • Linux server owner
    • x64 @roblourens
    • x64 Alpine
    • ARM32 @roblourens
    • ARM64
    • ARM64 Alpine
• Publish website @gregvanl
• Publish to stable @rebornix
• Trigger the vscode.dev Deploy pipeline for the prod deployment target. Request approval from another team member at the necessary step. @rebornix
• Create an official release @rebornix
  • 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
• Twitter announcement @chrisdias
• Enable scheduled insider builds @rebornix
• Bump up the version in package.json on main - @rebornix
• Publish @types/vscode @rebornix
• Close the milestone on GitHub @rebornix
• 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 @rebornix
• If no Patch Tuesday release is planned, let the Updates team know of that fact ([email protected]) @rebornix
• If a recovery build is needed, proceed to https://github.com/microsoft/vscode/wiki/Endgame-Recovery-Template or https://github.com/microsoft/vscode-internalbacklog/wiki/Patch-Tuesday-Release-Endgame-Template/ @rebornix

[lorand-horvath]

@rebornix I've been noticing a bit of confusion regarding the "version" property in https://github.com/microsoft/vscode/blob/main/package.json during the phase before releasing a new version. So, for example during Monday-Wednesday before the planned release 1.73 this week Wednesday, we see "version": "1.73.0" for the main branch, but in fact it should be "1.74.0", since the main branch has already been worked on with commits belonging to 1.74 (November release)

Wouldn't it be more logical to switch the main branch version to 1.74 immediately after the release/1.73 branch was created (Friday last week, AFAICT) and just before work begins on 1.74?

If this change were done, you wouldn't need the Bump up the version in package.json on main entry anymore for Wednesday/Thursday.

[rebornix]

@lorand-horvath thanks for the reminder and it makes good sense to bump version in the main branch right after we create the release branch.

[lorand-horvath]

@rebornix Looks like it didn't work as expected: 447e61a

[joaomoreno]

It should've worked. It will work from now on: #165132