Support notification on pwsh startup when a new release is available

[daxian-dbw]

PR Summary

RFC: PowerShell/PowerShell-RFC#162
Support notification on pwsh startup when a new release is available

• Preview pwsh will check both new preview and stable releases. It prints notification message at startup time as long as the latest preview version or stable version is higher than the current version.
• Stable pwsh will check new stable releases only. It prints notification message at startup time if the latest stable version is higher than the current version.
• Update check and notification will only happen for interactive sessions, and it can be suppressed by both the -NoLogo flag and an environment variable POWERSHELL_UPDATECHECK_OPTOUT.
• Update check is done by a task that is delayed for 3 seconds after pwsh starts, so it has minimum impact to the startup time.

For detailed implementation design, please look at the RFC.

Notification Message

For stable version pwsh:

C:\Users\user>e:\6.2.1\pwsh.exe -noprofile
PowerShell 6.2.1
Copyright (c) Microsoft Corporation. All rights reserved.

https://aka.ms/powershell
Type 'help' to get help.

!! A new PowerShell stable release is available: v6.2.3 !!
Upgrade now, or check out the release page at:
https://github.com/PowerShell/PowerShell/releases/tag/v6.2.3

PS C:\Users\user>

For preview version pwsh:

C:\Users\user>e:\preview\pwsh.exe -noprofile
PowerShell 6.2.0-preview.3
Copyright (c) Microsoft Corporation. All rights reserved.

https://aka.ms/powershell
Type 'help' to get help.

!! A new PowerShell preview release is available: v7.0.0-preview.4 !!
Upgrade now, or check out the release page at:
https://github.com/PowerShell/PowerShell/releases/tag/v7.0.0-preview.4

PS C:\Users\user>

Startup Perf Measurement on my dev machines

Windows

When no new release is available, namely on the latest preview/stable pwsh where notification will not be printed, the update notification change adds about 4ms to the startup time of an interactive session.

• 2ms spent on starting the update-check task
• 2ms spent on the notification printing logic

When a new release is available, namely on an old preview/stable pwsh where a notification message will be printed, the update notification change adds about 6ms to the startup time of an interactive session.

• 2ms spent on starting the update-check task
• 4ms spent on the notification printing logic

As a reference, Measure-Command { F:\pscore70.preview4\pwsh.exe -noprofile -c exit } takes about 400ms on average on my Windows dev machine.

Linux (Ubuntu 16.04)

When no new release is available, namely on the latest preview/stable pwsh where notification will not be printed, the update notification change adds about 6ms to the startup time of an interactive session.

• 3ms spent on starting the update-check task
• 3ms spent on the notification printing logic

When a new release is available, namely on an old preview/stable pwsh where a notification message will be printed, the update notification change adds about 9ms to the startup time of an interactive session.

• 3ms spent on starting the update-check task
• 6ms spent on the notification printing logic

As a reference, Measure-Command { pwsh-preview -noprofile -c exit } takes about 445ms on average on my Linux dev machine.

macOS (10.14.6)

When no new release is available, namely on the latest preview/stable pwsh where notification will not be printed, the update notification change adds about 4ms to the startup time of an interactive session.

• 2ms spent on starting the update-check task
• 2ms spent on the notification printing logic

When a new release is available, namely on an old preview/stable pwsh where a notification message will be printed, the update notification change adds about 5ms to the startup time of an interactive session.

• 2ms spent on starting the update-check task
• 3ms spent on the notification printing logic

As a reference, Measure-Command { pwsh-preview -noprofile -c exit } takes about 316ms on average on my macOS dev machine.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s): PSUpdatesNotification
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed: Add documentation about the new release notification feature MicrosoftDocs/PowerShell-Docs#4881
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[rjmholt]

Implementation looks really nice to me. Left a couple of comments but generally looks really good

[daxian-dbw]

@rjmholt Thanks for the review and feedback! I addressed them all. Also, I decided to use using declaration in QueryNewReleaseAsync to make it less nested.
Can you please take another look?

[daxian-dbw]

@joeyaiello Could you please take a look at the current notification message in the PR description? I decided to not print it in color as it's (1) over striking (annoying) (2) not accessibility friendly.

[rjmholt]

LGTM!

[daxian-dbw]

Rebased to resolve a conflict in experimental feature declaration.

[iSazonov]

No tests was added.

[daxian-dbw]

@iSazonov I don't know how to add a test for it. It seems manually testable only -- only interactive session will trigger update-check and notification-printing.

[iSazonov]

We could use HttpListener helper module to emulate server responses, HelpersHostCS to get host output, and test hook to force update check. Although I'm not sure it is worth the effort. Maybe after it ceases to be experimental.

[bergmeister]

@daxian-dbw
It does not seem to be aware of the daily build though.

A bit of a late feedback: All the exclamation marks make it look very non-standard and not so professional. Generally, I'd recommend to not use any exclamation marks at all as this is a purely informative message (after the first time the user might be very well aware of it). It would be great if it did some maths around the support time whether the current version is still in support or not.

[SteveL-MSFT]

@bergmeister I'm going to do an update to the message. Let me look at some examples from other software.

[iSazonov]

@bergmeister This is an experimental feature and feedbacks is not a late. And we were more worried about the code than about the look. :-)

[iSazonov]

Upgrade now

Not clear how.

[daxian-dbw]

@bergmeister Thanks for the feedback! I was expecting @joeyaiello to take a look at the message but he was busy and didn't get to it.
As @iSazonov said, this PR is more about implementation, and the message will be updated based on feedback.