You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add ability to auto update Insiders build of extension #2772
Updating label to code health + enhancement.
I.e. even if not exposed to end users, it would be good for in-house use. Much like out of band LS installs.
Note: This is not for extension authors. That python file builds the extension.
This is for users of the developer build of the extension, i.e. dog fooding.
VSC doesn't provide a pre-release channel of extensions, and that's why we host our extension on a blob store, and users need to install it manually.
The benefit, is:
We'll have a regular set of users who are constantly testing/using the dev version of the extension.
We have the potential to get feedback before the release.
Either way, this would be great for in house developers.
UX (similar to out of band installs of LS):
Download and install extension daily, weekly
Manual download and install of the extension (via some command)
Will need to consider impact of downloading LS every time we update the extension (e.g. if we update extension every day, then LS will be downloaded every day).
changed the title [-]Add ability to auto update developer build of extension[/-][+]Add ability to auto update Insiders build of extension[/+]on Feb 26, 2019
The problem is if you install via .vsix you will get it immediately overwritten by the "Stable" default setting. The proposed fix is:
Drop "Stable"
Add a "default" setting which is "we do nothing, VS Code handles things"
Rename "InsidersWeekly" and "InsidersDaily" to "weekly" and "daily", respectively)
This will then let .vsix installs work as expected. People can revert back using the built-in support in VS Code for rolling back to older versions. This also won't break people who are using forks of the extension as otherwise we would start forcibly updating them to stable or our insiders builds instead of their fork.
Suppose a user is using "weekly/daily", and he decides to install an older version of the extension. He would still be forced to use the insiders version of the extension. I don't think we want that either.
Kartik Raj (@karrtikr) I don't think it can be avoided. If you want to control what version of the extension you want installed you then need to be on the "default" setting to let VS Code handle it for you, otherwise you're handing installation control to us under "weekly" and "daily".
I have verified that I now have a "python.insidersChannel" user setting. Switching it to "daily" it immediately downloaded the .vsix and prompted me to reload. So that all looks good.
However...
From #2772 (comment) I gather that, when using insiders already, I was supposed to be prompted about what I wanted to do. I was never prompted. It simply used the default setting, "off". That's fine, but if that expected prompt was a requirement for this feature then this issue needs more work.
Activity
d3r3kk commentedon Oct 3, 2018
We already have the python file to do this...
DonJayamanne commentedon Oct 4, 2018
Note: This is not for extension authors. That python file builds the extension.
This is for users of the developer build of the extension, i.e. dog fooding.
VSC doesn't provide a pre-release channel of extensions, and that's why we host our extension on a blob store, and users need to install it manually.
The benefit, is:
Either way, this would be great for in house developers.
UX (similar to out of band installs of LS):
DonJayamanne commentedon Jan 17, 2019
Luciana Abud (@luabud) /cc
DonJayamanne commentedon Feb 7, 2019
Will need to consider impact of downloading LS every time we update the extension (e.g. if we update extension every day, then LS will be downloaded every day).
See #4323
[-]Add ability to auto update developer build of extension[/-][+]Add ability to auto update Insiders build of extension[/+]DonJayamanne commentedon Feb 27, 2019
DonJayamanne commentedon Mar 27, 2019
Prescribed Solution
vscode.commands.executeCommand('workbench.extensions.installExtension', Uri.file('path-to-vsix'));Check spec for UX
29 remaining items
brettcannon commentedon Jul 11, 2019
Making manual installs work
The problem is if you install via
.vsixyou will get it immediately overwritten by the"Stable"default setting. The proposed fix is:This will then let
.vsixinstalls work as expected. People can revert back using the built-in support in VS Code for rolling back to older versions. This also won't break people who are using forks of the extension as otherwise we would start forcibly updating them to stable or our insiders builds instead of their fork.karrtikr commentedon Jul 12, 2019
Suppose a user is using "weekly/daily", and he decides to install an older version of the extension. He would still be forced to use the insiders version of the extension. I don't think we want that either.
brettcannon commentedon Jul 12, 2019
Kartik Raj (@karrtikr) I don't think it can be avoided. If you want to control what version of the extension you want installed you then need to be on the "default" setting to let VS Code handle it for you, otherwise you're handing installation control to us under "weekly" and "daily".
ericsnowcurrently commentedon Aug 1, 2019
I have verified that I now have a
"python.insidersChannel"user setting. Switching it to "daily" it immediately downloaded the .vsix and prompted me to reload. So that all looks good.However...
From #2772 (comment) I gather that, when using insiders already, I was supposed to be prompted about what I wanted to do. I was never prompted. It simply used the default setting, "off". That's fine, but if that expected prompt was a requirement for this feature then this issue needs more work.
Luciana Abud (@luabud), what needs to be done here?
ericsnowcurrently commentedon Aug 5, 2019
FWIW, Don manually double-checked about the prompt. It worked as expected. I must have been prompted a while back and VS Code still remembered.