Document: Fetch last compatible version of extensions

[rebornix]

This idea has probably been already discussed before but I didn't find the exact issue. @TylerLeonhardt and me discussed how VS Code supports stable/beta releases of extensions without the marketplace doing anything, and found this doable in practice:

• Extensions publish
  • Publish a version 1.0, with engine set to 1.51 (note that there is no ^ so we publish a version targeting VS Code Stable 1.51)
  • Publish a version 1.1 with engine set to 1.52-Insider. This version will only work in 1.52 Insiders
  • Then publish a version 1.2 with engine set to 1.51 if there are important bug fixes need to ship to users on VS Code 1.51
  • Continue publishing versions 1.x with engine 1.52-Insider
• VS Code
  • We fetch the last compatible version for current distro. For example, VS Code Insiders will always get the last version whose engine is set to 1.52-Insider while Stable users will get the last one with engine 1.51

With above approach, extensions can use the same extension for different distro, which is helpful for testing proposed api. It's different from support beta version of extensions.

[TylerLeonhardt]

• VS Code
  *We fetch the last compatible version for current distro. For example, VS Code Insiders will always get the last version whose engine is set to 1.52-Insider while Stable users will get the last one with engine 1.51

we could do something similar to nuget.org

in old vscode versions, show the latest you can install with a disclaimer saying "hey this is not the latest! but it's the newest you can install"

• Possible concerns:

  • The newest a VS Code version can install is really old
  • The newest a VS Code version can install has a security vulnerability

• Upsides:

  • SAWs (and similar enterprises that follow this practice) that don't have the newest version of VS Code on them can still install extensions with ease (without having to manually try old versions until it works)

[sandy081]

@rebornix We already support whatever you described in the description. I always fetch the latest extension version that supports the VS Code client from which the extension is asked to install / update.

I will close this unless you have other asks here. Following are other ideas being collected in issues

microsoft/vscode#15756
microsoft/vscode#111521

[TylerLeonhardt]

My bad, I thought I had seen different behavior in the past... One thing that tripped me up though:

Steps:

1. Download v1.48 of VS Code
2. Go to extensions pane and search for GitHub Pull Request (whose latest version, 0.22.0, has engine at 1.53)
   
3. Click install

Actual:
0.20.0 installs

Expected:
The marketplace to say the actual version I'm allowed to install (0.20.0)

Without this, it's misleading to the customer as to what version they can actually install. They will also be confused to see that the listing says 0.22.0 and they only got 0.20.0.

[rebornix]

Other than the issue @TylerLeonhardt described above, it works as expected. @sandy081 do you think we can document this and extension authors can rely on this behavior in their release pipeline? If this behavior is golden, extensions can have a release story similar to ours

• After VS Code 1.x releases, release a new extension targets 1.x, create a release branch for the extension
• For critical bug fixes, they go into the release branch and publish new versions with engine set to 1.x
• Master is always published to 1.${x+1}-insiders

This can be a fine story for extensions currently using proposed api but not interested in publishing multiple extensions.

[gjsjohnmurray]

Isn't there a Marketplace restriction that prevents publication of an extension in which "enableProposedApi": true?

[eamodio]

This also makes the assumption that you only want to allow your "beta" version to work with insiders builds, which I don't think is always the case. For example, I currently have an "insiders" edition of GitLens, and its engine only locked to the feature set it requires. So users can use it on any version of VS Code that meets those needs.

Do we also consider 1.53 greater than 1.53-insiders? Meaning if you said you want 1.53-insiders won't you still get that version on 1.53?

[rebornix]

@eamodio this is particularly for releasing features using latest proposed in Insiders, it's different from "beta" as that's talking about shipping extension specific preview features (not necessarily limited by vscode api).

If extensions set engine to 1.53-insiders (no ^), users on 1.53 should not get it as 1.53 !== 1.53-insiders.

[sandy081]

Filed separate issue for tracking showing extension with compatible version. I wonder if this needs support from Marketplace team too.

[sandy081]

do you think we can document this and extension authors can rely on this behavior in their release pipeline?

@rebornix Sure. We can have one of our extensions as an example following this and document it.

[rebornix]

I just verified that the extension update flow works exactly as described above, thanks @sandy081 for confirmation, it works great. It should be the recommended solution for extensions who want to differentiate Stable and Insiders distro.

[gjsjohnmurray]

@rebornix @sandy081 I previously asked here:

Isn't there a Marketplace restriction that prevents publication of an extension in which "enableProposedApi": true?

If that's still the case then I don't see how we extension developers can make this work.