Follow up questions to https://github.com/microsoft/vscode/issues/270285

[kevineger]

Hey @DonJayamanne - I'm starting this separate discussion thread to not create too much noise on the active issue microsoft/vscode#270285. I had a few follow-up questions:

1. Regarding your note here, If this was identified sooner we would have patched it (thats the general practice): given that the issue couldn't surface until the extension marketplace was serving the new version, I don't think it could have been detected much sooner. But wouldn't an e2e test for the Jupyter extension that uses the VS Code extension tester have found this? At time of writing, the stable VS Code version was 1.104. Bumping the engine to 1.105 should cause that vsix not to install/work in the test.
2. Also in the same note, w.r.t. There's no way to patch the Jupyter extension, wouldn't patching 2025.9.0 to 2025.9.1 with the VS Code engine set to 1.104 fix the issue (for all those with auto-update enabled)? They'd get the new update, which would successfully install and not rollback to the last platform-agnostic version (2023).
3. As mentioned in my initial issue report, I develop an extension which registers a JupyterServerProvider. As such, my extension lists an extensionDependencies on "ms-toolsai.jupyter". Ideally, my engine should be set to the same as Jupyter, or I risk a bunch of version drift or API incompatibility as things change. Any general guidance here? Should I just be in the habit of routinely updating to whatever the Jupyter extension has pinned?
4. I'm curious why the Jupyter extension is routinely bumping the engine to the bleeding edge of stable. Shouldn't it only need bumping when it starts depending on VS Code APIs only available in newer versions? Mostly looking to understand rationale here so I can best set my own value. Isn't it in your (the maintainer's) best interest to have older VS Code installs on the newer version of the extension so they get improvements and bug-fixes, when the dependent VS Code API allows? By bumping the engine aggressively, it increases the chance users are served an old compatible version instead of latest. To be clear, I don't mean this as a critique; I'm genuinely trying to understand best practices here so I can apply them to my own extension(s).

[DonJayamanne]

thanks for the questions, will try to answer all of them.

I don't think it could have been detected much sooner. But wouldn't an e2e test for the Jupyter extension that uses the VS Code extension tester have found this?

We install the latest version by installing from VSIX, (as the extensions and vscode will not have been shipped)

There's no way to patch the Jupyter extension, wouldn't patching 2025.9.0 to 2025.9.1 with the VS Code engine set to 1.104

No, the issue isn't with the version or engine. its to do with VS Code changes (pelase see the PR that fixes this in VS Code). that broke it. It would have broken for other extensions as well (that have platform specific vsix)

Any general guidance here? Should I just be in the habit of routinely updating to whatever the Jupyter extension has pinned?

Not required, generally you should just expect your extension to work with the latest version of Jupyter.
The only reason pinning is required is

• If you use some API thats only available in a specific version of VS Code (this way users will not be able to install your extension on old version of vscode that doesn't have a specific API)

ter extension is routinely bumping the engine to the bleeding edge of stable. Shouldn't it only need
For jupyter we pin it simply because we only support the ver latest version of vs code.
I.e. if users report issues in VS Code thats a year old and latest version of Jupyter extension (thats not a scenario we want to support actively)

Isn't it in your (the maintainer's) best interest to have older VS Code installs on the newer version of

Its in best interest of users, to ensure they have latest version of vscode if they want latest version of jupyter.
This ensures they have fixes from both worlds. supporting older versions of vscode is just taxing, where do we draw the line.

bumping the engine aggressively, it increases the chance users are served an old compatible version instead of latest. T

This will will not happen.
VS Code doesn't allow installing an extension thats pinned to an engine thats greater than the version of vscode you have.
I.e. if you install last years version of VS Code and try to install jupyter from marketplace. it will only install Jupyter extnsion thats a year old.
This actually helps users to be able to easily use old versions of vs code and install extensions from marketplace without having to worry about versions/engine compatibility manully). All of this is automatically handled in vs code.

The bug we have today is just that, a bug (never had this before, sadly introduced 2-3 versions ago).
It resulted in installing a 2 year old version (not specific to Jupyter or engine pinning in any way), its specific to platform versions, see PR & comments from Sandy.