Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document: Fetch last compatible version of extensions #4318

Open
rebornix opened this issue Jan 27, 2021 · 12 comments
Open

Document: Fetch last compatible version of extensions #4318

rebornix opened this issue Jan 27, 2021 · 12 comments
Assignees
Labels
doc-enhancement suggested addition or improvement extensibility extension author content under /api

Comments

@rebornix
Copy link
Member

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
Copy link
Member

  • 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

image

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
Copy link
Member

@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
Copy link
Member

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)
    image
  3. Click install

Actual:
0.20.0 installs
image

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
Copy link
Member Author

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
Copy link
Contributor

gjsjohnmurray commented Jan 28, 2021

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

@eamodio
Copy link
Contributor

eamodio commented Jan 28, 2021

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
Copy link
Member Author

@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
Copy link
Member

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

@sandy081
Copy link
Member

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 rebornix changed the title Fetch last compatible version of extensions Document: Fetch last compatible version of extensions Feb 9, 2021
@rebornix
Copy link
Member Author

rebornix commented Feb 9, 2021

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.

@rebornix rebornix transferred this issue from microsoft/vscode Feb 9, 2021
@gjsjohnmurray
Copy link
Contributor

@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.

@gregvanl gregvanl added doc-enhancement suggested addition or improvement extensibility extension author content under /api labels Feb 9, 2021
@gregvanl gregvanl added this to the April 2021 milestone Mar 24, 2021
@gregvanl gregvanl modified the milestones: April 2021, May 2021 Apr 30, 2021
@gregvanl gregvanl modified the milestones: May 2021, June 2021 May 29, 2021
@sandy081 sandy081 removed this from the June 2021 milestone Jul 1, 2021
@mrzezoo
Copy link

mrzezoo commented Oct 7, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc-enhancement suggested addition or improvement extensibility extension author content under /api
Projects
None yet
Development

No branches or pull requests

7 participants