[x] Ensure that any CI test failures have issues assigned to that area's owner.
[x] Work with the build champ to drive the build to green by fixing/disabling tests or pinging area owners to do so.
Friday
[x] Review Component Governance (Click on "microsoft/vscode-jupyter" on that page) and resolve all High/Severe issues.
[x] Focus on resolving Critical and High priority issues as others will be addressed in the debt week.
[x] 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.
[x] Create new release branch with format release/release-YYYY.MM.
Note: The release branch should not be changed after this step (not including hotfixes)
[x] Create a PR to main with the following changes... (Warning: this should happen right after creating the release branch. If this is deferred till later, the main and release branches can diverge significantly, which may cause merge conflicts.)
[x] 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.
[x] 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)
[x] Windows
[x] win32-x64 @Yoyokrazy
[x] win32-arm64 @DonJayamanne
[x] macOS
[x] darwin-x64 @DonJayamanne
[x] darwin-arm64 @DonJayamanne
[x] Linux
[x] linux-arm64 @DonJayamanne
[x] linux-armhf @DonJayamanne
[x] linux-x64 @DonJayamanne
[x] alpine-arm64 @DonJayamanne
[x] alpine-x64 @DonJayamanne
[x] 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
[x] 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.
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)
[x] Verify the PR Pipeline on Github actions is green against the release branch.
[x] Approve the Publish stage of the last Stable pipeline that's successfully sanity tested.
[x] 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.
[x] 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)
[x] 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
Thursday
Friday
CriticalandHighpriority issues as others will be addressed in thedebtweek.npmdependencies inpackage.json&package-lock.jsoncan be found here.release/release-YYYY.MM.mainwith the following changes... (Warning: this should happen right after creating the release branch. If this is deferred till later, themainandreleasebranches can diverge significantly, which may cause merge conflicts.)mainto the next monthly ("YYYY.M.0") version number (e.g. if the latest is2022.2.0, bump it to2022.3.0).npm installto updatepackage-lock.jsonMonday (Debt/Release week)
release/release-YYYY.MMbranchPublish Extension, you do not need an approval to build the VSIX.Dev Containers: Reopen in Container)mainand cherry-picked toreleasebranchSatelite extensions/npm packages
zeromq-prebuiltTuesday
Publishstage of the last Stable pipeline that's successfully sanity tested.PublishStage of the stable pipeline linked above.endgame_plan.mdfile to make it clear for the next releaseWednesday/Thursday (Day of VS Code releasing the next insider version)
mainbranch to point to the next version. For example, from1.58.0to1.59.0As needed
release/release-YYYY.MMbranchYYYY.MM.0, then hot fix will beYYYY.MM.1YYYY.MM.1, then hot fix will beYYYY.MM.2Dev Containers: Reopen in Container)PublishStage of the stable pipeline linked above, and manually add one using:git tag -a YYYY.MM -m YYYY.MM -s -f