September Endgame

[Yoyokrazy]

• Endgame Template

Thursday

• Ensure that any CI test failures have issues assigned to that area's owner.
• Work with the build champ to drive the build to green by fixing/disabling tests or pinging area owners to do so.

Friday

• Review Component Governance (Click on "microsoft/vscode-jupyter" on that page) and resolve all High/Severe issues.
  • Focus on resolving Critical and High priority issues as others will be addressed in the debt week.
  • Manually add any repository dependencies (if you can't add manually, refer here). Only add a cgmanifest.json if the components are not NPM or are not dev only.
    Instructions on updating npm dependencies in package.json & package-lock.json can be found here.
• Create new release branch with format release/release-YYYY.MM.
  • Note: The release branch is now ready for to be published (or hotfixed)
• Back on the main branch, bump the version in package.json.
  • The version number will be the next monthly ("YYYY.M.0") version number (e.g. if the latest is 2022.2.0, bump it to 2022.3.0).
  • npm install to update package-lock.json as well

Monday (Debt/Release week)

• Obtain VS Code stable RC for sanity testing
• Manually run the Stable pipeline against the release/release-YYYY.MM branch
  • Enable Publish Extension, you do not need an approval to build the VSIX.
  • DO NOT ask for approval for the extension publish step, this step should only be done after sanity testing is done and ready to release.
• Sanity test release candidate VSIX against VS Code RC
  Tip: You can use the dev containers in the this repo for testing against linux (just open the repo and use thd command Dev Containers: Reopen in Container)
  • Windows
    • win32-x64 (tip: use https://devbox.microsoft.com/) @DonJayamanne
    • win32-arm64 @DonJayamanne
  • macOS
    • darwin-arm64 @DonJayamanne
    • darwin-x64 (tip: use rosetta mode, see below)

Tip

Testing Mac x64 on Apple Silicon as follows
Install Mac Universal version of Code
Right click on the app in finder and select Get Info
Select the option Open using Rosetta
Open VS Code
Its very very slow, (some times just hangs forever, might crash/restart, after all its an emulation).

• Linux (tip: use VS Code sanity testing https://github.com/microsoft/vscode/wiki/Sanity-Check#linux-using-the-clitunnels)
  • linux-arm64 @DonJayamanne
  • linux-armhf @DonJayamanne
  • linux-x64 @DonJayamanne
  • alpine-arm64 @DonJayamanne
  • alpine-x64 @DonJayamanne
• Test web by going to insiders.vscode.dev and test the latest pre-release of jupyter
• Candidate bug fixes found from sanity test should be checked into main and cherry-picked to release branch
  • After a candidate fix is merged, a pre-release build can be released by manually running the pre-release devops pipeline against the release branch.

Satelite extensions/npm packages

• Reach out to the owners of each of these to coordinate the releases (if any).
  • If there are no releases for each of the following, then mark them as done.
  • Else the ownsers of each to mark as done when they are done.
• JupyterHub (@DonJayamanne)
  • No need to pin VS Code engine
  • Release directly from main branch (pipeline)
  • PreRelease directly from main branch manually (pipeline)
• Jupyter (Notebook) Renderers (@DonJayamanne)
  • No need to pin VS Code engine (unless you want to test something against VS Code insiders and not ship to stable users)
  • Release directly from main branch (pipeline)
• Jupyter Powertoys (@DonJayamanne)
  • No need to pin VS Code engine (unless you want to test something against VS Code insiders and not ship to stable users, e.g. depends on some new Jupyter Extension API)
  • Release directly from main branch (pipeline)
• Jupyter Cell Tags (@rebornix)
  • No need to pin VS Code engine
  • Release directly from main branch (pipeline)
• Jupyter Slideshow (@rebornix)
  • No need to pin VS Code engine
  • Release directly from main branch (pipeline)
• Jupyter KeyMap (@rebornix)
  • No need to pin VS Code engine
  • Release directly from main branch (pipeline)
• Tensorboard (@DonJayamanne)
  • No need to pin VS Code engine
  • Release directly from main branch (pipeline)
  • PreRelease directly from main branch manually (pipeline)
• zeromq-prebuilt (@DonJayamanne)
  • Release directly from main branch (pipeline)
  • Release by adding a git tag and pushing it upstream (e.g. 6.0.0-beta.16.8)
  • Can test bundles by manually running and publishing releases to github releases (download and test the bundles manually from github releases)
• @vscode/zeromq (@DonJayamanne)
  • To be done after relesing zeromq-prebuilt
  • Release directly from main branch (pipeline)
• @vscode/jupyter-extension (@DonJayamanne)
  • Release directly from main/relese branch (pipeline)
• Gather (@DonJayamanne)
  • No need to pin VS Code engine
  • Release directly from main branch (pipeline)

Tuesday

• Make sure Component Governance is happy
• Release
  • Verify the PR Pipeline on Github actions is green against the release branch.
  • Approve the Publish stage of the last Stable pipeline that's successfully sanity tested.
  • Ensure a tag with the released version number on the commit that was released was created.
    • This step occurs in the Publish Stage of the stable pipeline linked above.
  • If any steps were unclear or changed in this endgame plan please update the endgame_plan.md file to make it clear for the next release

Wednesday/Thursday (Day of VS Code releasing the next insider version)

• Bump the engines.vscode version on the main branch to point to the next version. For example, from 1.58.0 to 1.59.0

As needed

• Determine if a hotfix is needed
  • Use the same release/release-YYYY.MM branch
• Ensure the version in package.json is updated as follows:
  • If released version is YYYY.MM.0, then hot fix will be YYYY.MM.1
  • If released version is YYYY.MM.1, then hot fix will be YYYY.MM.2
• Verify all candidate issues
• Sanity test release candidate VSIX against VS Code RC
  Tip: You can use the dev containers in the this repo for testing against linux (just open the repo and use thd command Dev Containers: Reopen in Container)
  • Windows
    • win32-x64 @Yoyokrazy
    • win32-arm64 @DonJayamanne
  • macOS
    • darwin-x64 @DonJayamanne
    • darwin-arm64 @DonJayamanne
  • Linux
    • linux-arm64
    • linux-armhf
    • linux-x64
    • alpine-arm64
    • alpine-x64
• Ensure that another tag was created for the new version's commit.
  • If a tag was not pushed, investigate in the Publish Stage of the stable pipeline linked above, and manually add one using: git tag -a YYYY.MM -m YYYY.MM -s -f

[sandy081]

@DonJayamanne Can this be closed?

[DonJayamanne]

We keep this open for candidates and the like.

[sandy081]

I see. Then can you please change the milestone since September 2025 is closed.