We've had some difficulties coordinating breaking changes to proposed API between VS Code and an extension. Summarizing the problems and what we're trying to do about them:

I want to be able to land a PR with the API change in VS Code, and at the same time, a PR to adopt it in the extension. And, at extension install time or runtime, we want to be able to ensure that the installed extension is compatible with the current version of vscode

• On one end, it's hard to use the engines.vscode version to handle the case where the extension gets ahead of the VS Code version, because at the time we want to land the extension PR, that version of VS Code has not been published yet, so we can't run extension tests with it
• On the other end, there is no good way to know when the extension is behind the VS Code version because we normally assume that extension API updates are backwards-compatible.

Things we've discussed

• Merging PRs in the extension
  • Manually kick off a build of VS Code to use when landing the extension PR, and vscode-test will download this build
  • Or build VS Code in CI automatically and cache it across builds. It shouldn't take too long to do a bare-minimum OSS build with no tests
  • Either way, we ignore the date part of the engine version (because it will be tomorrow's version)
• Detecting at runtime when the extension is behind
  • A runtime version check for the chat API. We already have this but can't use it currently because it has the same problems as above
  • An API proposal version as an official concept in VS Code- don't load an extension that doesn't support the correct current version of the proposal
• Can we improve this at install-time?
  • @sandy081 suggested locking the extension engine version to a single VS Code version, rather than using it as a "minimum" version
  • Then we can check this in the marketplace and install the proper version
  • This would prevent users from installing the stable extension on VS Code Insiders
• Change how pre-release works to force installing pre-release in Insiders, if it has a pre-release
  • Sandeep suggested making this change for all extensions
  • A downside is that some users may still want to be able to use Insiders without also using pre-release extensions
  • And, an extension might have stopped publishing pre-releases, so it has some but they are very out of date
  • Also see Installing Copilot in Insiders can cause stable Copilot Chat to be installed, not pre-release #213959 for a case where currently it's possible for Insiders users to get the stable Copilot Chat by default
• If a pre-release extension build is delayed, it can leave users unable to use Copilot Chat
  • There's probably no decent solution to this, since the two builds should be independent, but it is not a common issue