-
Notifications
You must be signed in to change notification settings - Fork 123
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
Support notification on pwsh
startup when a new update is available
#162
Support notification on pwsh
startup when a new update is available
#162
Conversation
Co-Authored-By: daxian-dbw <dongbow@microsoft.com>
Co-Authored-By: daxian-dbw <dongbow@microsoft.com>
@daxian-dbw Should we have a different message mentioning a security update is available for GA releases? The urgency of updating a preview v/s a GA with security patch is different. |
@adityapatwardhan Is there a way to know a release is a security release by querying GitHub/release? Or do we need to have a back end to provide that information? |
@daxian-dbw I'll publish security advisories here: https://github.com/powershell/powershell/security/advisories?state=published There probably is an API to read this |
Talked to @adityapatwardhan offline about his comment.
So whether a new stable release is a security patch or not, a stable release of |
@chuanjiao10 The auto-upgrade is not a goal of this feature. |
FWIW, this is the exact behavior of the "update PowerShell" feature that ships in the PowerShell extension for VS Code. So it's nice that we're consistent there. |
Actually @daxian-dbw if you wanna mention that you are leaving the auto-upgrade capability to the VS Code extension since that can make assumptions that powershell itself can't, that might be worthwhile to add to the RFC. |
Windows 10 has different channels:
Also it seems @bergmeister shared that he install nightly builds every day. Perhaps makes sense follow Windows 10 and also use slow and fast rings. |
Per conversation with @rjmholt and @SteveL-MSFT today, we have to think about LTS implications here as well. If I'm on 7.0 LTS and a hypothetical 8.0 stable (non-LTS) comes out, am I being notified about its release? (Ideally, no, but nothing in our implementation addresses this today.) We should also validate that if 7.0 preview gets "updated" (i.e. side-by-sided) by 7.0 stable, and then a hypothetical 7.1 preview comes out, that 7.0 preview is prompting for update to 7.1 preview. |
Coming out of @PowerShell/powershell-committee review, we want to change the environment variable to no longer be a simple opt-out/in but rather a field that can be used to set the "channel". So e.g. a |
Since it is a configuration option I'd expect that it will be in config. Moreover, users will not change this often. Most likely only during installation (installer option).
|
On the topic of configuration... this feature might also need to support configuration of Proxies since a percentage of the folks we're trying to notify will be behind a proxy? It might just work already. We just received an issue in vscode-powershell for supporting proxies. This type of configuration is very simple in the PowerShell extension, but I wonder where the best candidate is for this type of configuration in PowerShell... I think in config is probably the best way to do it but then it will need some sort of cmdlet to set these values. |
@TylerLeonhardt By default HttpClient() uses a system default proxy, also it read environment variables like |
@daxian-dbw to update this with the latest env variable info, and then @PowerShell/powershell-committee can approve |
Only have me, @daxian-dbw, and @SteveL-MSFT in the room, but we're all ready to accept and merge |
then a notification about the new release may show up on the same day, | ||
but is guaranteed no later than the next day. | ||
|
||
2. If an update check detects a new release, the notification should show up in the same session. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from an implementation perspective, if this is done as a Cmdlet
it should be possible for a user to check if a new version is available at any time.
Will update the RFC to mention that the notification message is rendered in inversion. |
Comments: make it explicit that this applies to the PowerShell console host only, and add in the 'alternate proposal' that we may consider to add an API in the engine to check for updates. |
Support notification on
pwsh
startup when a new update is available.Today, to find out whether a new version of PowerShell is available, one has to check the release page of the
PowerShell\PowerShell
repository, or depend on communication channels liketwitter
orGitHub Notifications
. It would be convenient ifpwsh
itself can notify the user of a new update on startup.