Dongbo Wang (@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.

Aditya Patwardhan (@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?

Dongbo Wang (@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 Aditya Patwardhan (@adityapatwardhan) offline about his comment.

• pwsh of preview versions should check for the new preview version as well as the new GA version.
• pwsh of GA versions should check for the new GA version only

So whether a new stable release is a security patch or not, a stable release of pwsh will report it as A new PowerShell stable release is available.

chuanjiao10 The auto-upgrade is not a goal of this feature.

Talked to Aditya Patwardhan (@adityapatwardhan) offline about his comment.

pwsh of preview versions should check for the new preview version as well as the new GA version.
pwsh of GA versions should check for the new GA version only

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 Dongbo Wang (@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.

pwsh of preview versions should check for the new preview version as well as the new GA version.
pwsh of GA versions should check for the new GA version only

Windows 10 has different channels:

1. Preview - check preview and GA, continue checks preview after install GA - I believe this is that users expect.
2. GA - checks only GA

Also it seems Christoph Bergmeister (@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 Rob Holt (@rjmholt) and Steve Lee (@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 $env:PSNotificationPreference that can be set to Default, Off, or LTS, where the latter would only provide LTS update notifications in their notifications.

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

that can be set to Default, Off, or LTS

• Default - LTS on GA, Preview on Preview version
• LTS
• Preview
• None

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

Dongbo Wang (@daxian-dbw) to update this with the latest env variable info, and then @PowerShell/powershell-committee can approve

Only have me, Dongbo Wang (@daxian-dbw), and Steve Lee (@SteveL-MSFT) in the room, but we're all ready to accept and merge

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.