May Endgame

[DonJayamanne]

• 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
    • win32-arm64
  • macOS
    • darwin-x64
    • darwin-arm64
  • Linux
    • linux-arm64
    • linux-armhf
    • linux-x64
    • alpine-arm64
    • alpine-x64
• 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
    • win32-arm64
  • macOS
    • darwin-x64
    • darwin-arm64
  • 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