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

• 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 ofpwsh will report it asA new PowerShell stable release is available.

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

Talked to@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@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@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$env:PSNotificationPreference that can be set toDefault,Off, orLTS, 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 invscode-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 likeHTTP_PROXY.

@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

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.