← 输入框|github.com|刷新
Skip to content

Remove the Update Notification feature from PowerShell - #28242

Merged
Dongbo Wang (daxian-dbw) merged 1 commit into
PowerShell:masterfrom
daxian-dbw:remove-update-notification
Oct 20, 2026
Merged

Dongbo Wang (daxian-dbw) merged 1 commit into
PowerShell:masterfrom
daxian-dbw:remove-update-notification

Conversation

@daxian-dbw

@daxian-dbw Dongbo Wang (daxian-dbw) commented Oct 20, 2026 •

Copy link
Copy Markdown
Member

PR Summary

Fix #28131

Remove the Update Notification feature from PowerShell.

PowerShell servicing delivery through Microsoft Update has become increasingly mature and reliable, while PowerShell installed as an MSIX app can update automatically through the Microsoft Store. As these update mechanisms have improved, the in-product Update Notification provides increasingly limited additional value.

Removing the feature also eliminates its background network request, local cache and synchronization logic, startup notification, and associated maintenance overhead.

Changes

  • Remove the background check for new PowerShell releases.
  • Remove the update notification from the startup banner.
  • Remove the UpdatesNotification implementation and its cache-management logic.
  • Remove the default update-notification resource strings. Localized resources will be updated by the Localization Pipeline.
  • Remove obsolete POWERSHELL_UPDATECHECK setup from the startup banner tests.

PR Checklist

@daxian-dbw
Dongbo Wang (daxian-dbw) requested a review from a team as a code owner October 20, 2026 20:26
Copilot AI balanced review requested due to automatic review settings October 20, 2026 20:26
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

@daxian-dbw Dongbo Wang (daxian-dbw) added the CL-General Indicates that a PR should be marked as a general cmdlet change in the Change Log label Oct 20, 2026

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The removal is self-contained, preserves startup-banner assertions, and has no identified blocking issues.

No open issues 🎉

What changed in this PR

Removes PowerShell’s in-product update notifications, eliminating the startup crash path described in #28131 and associated background processing.

Changes:

  • Remove release checks, notification display, and cache-management implementation.
  • Remove default notification strings; localized cleanup is deferred to the Localization Pipeline.
  • Remove obsolete update-check environment setup from startup-banner tests.
File Description
test/​powershell/​Host/​ConsoleHost.Tests.ps1 Remove obsolete environment setup and restoration.
src/​Microsoft.PowerShell.ConsoleHost/​resources/​ManagedEntranceStrings.resx Remove default notification strings.
src/​Microsoft.PowerShell.ConsoleHost/​host/​msh/​UpdatesNotification.cs Delete the notification implementation.
src/​Microsoft.PowerShell.ConsoleHost/​host/​msh/​ConsoleHost.cs Remove background update-check startup.
src/​Microsoft.PowerShell.ConsoleHost/​host/​msh/​CommandLineParameterParser.cs Remove notification display from the banner.

Review effort: Balanced

@JoeSalmeri

Copy link
Copy Markdown

How will Linux installs that used tar.gz files be notified about an update being available ?

Seems like that use case was forgotten....

@kilasuit

Ryan Yates (kilasuit) commented Oct 27, 2026 •

Copy link
Copy Markdown
Collaborator

This PR closes this following discussion

Joe S (@JoeSalmeri) - Put simply they won't be notified & users that are using that install method will need to look to implement their own update check & install logic. My feeling is that the team felt if users are using that method for install on linux or MacOS or zip installs on Windows then they should already be capable of managing their own update check & install process.

Which can be done in a few lines of PowerShell easily enough via calling either

  • using the gh cli tool and gh release list --repo PowerShell/PowerShell
  • the release api for this repo https://api.github.com/repos/PowerShell/PowerShell/releases
  • via using the metadata.json file in this repo using sample code like this
    $metadata = Invoke-RestMethod 'https://raw.githubusercontent.com/PowerShell/PowerShell/master/tools/metadata.json'
    if ($Preview) {
    $release = $metadata.PreviewReleaseTag -replace '^v'
    } else {
    $release = $metadata.ReleaseTag -replace '^v'
    }
    if ($IsWinEnv) {
    if ($UseMSI) {
    $packageName = "PowerShell-${release}-win-${architecture}.msi"
    } else {
    $packageName = "PowerShell-${release}-win-${architecture}.zip"
    }
    } elseif ($IsLinuxEnv) {
    $packageName = "powershell-${release}-linux-${architecture}.tar.gz"
    } elseif ($IsMacOSEnv) {
    $packageName = "powershell-${release}-osx-${architecture}.tar.gz"
    }
    $downloadURL = "https://github.com/PowerShell/PowerShell/releases/download/v${release}/${packageName}"
    Write-Verbose "About to download package from '$downloadURL'" -Verbose
GitHub
PowerShell currently includes an update notification that informs users when a newer version of PowerShell is available. This feature was originally introduced to help users discover new releases, ...

@kwtobin

kwtobin commented Oct 27, 2026 •

Copy link
Copy Markdown

Ryan Yates (@kilasuit) - That seems like a leap to assume a typical user that downloaded a software package from Install PowerShell 7 on macOS once is ever going to go back and check it again manually.

It isn't like there haven't been significant CVE's that have needed patching recently that put Linux and macOS users at risk.

Feels like the 'security is a priority' focus went out the window with this decision.

@JoeSalmeri

Copy link
Copy Markdown

This PR closes this following discussion

Joe S (Joe S (@JoeSalmeri)) - Put simply they won't be notified & users that are using that install method will need to look to implement their own update check & install logic. My feeling is that the team felt if users are using that method for install on linux or MacOS or zip installs on Windows then they should already be capable of managing their own update check & install process.

Which can be done in a few lines of PowerShell easily enough via calling either

I already wrote a pwsh script to install a specific version pwsh version and I already check the releases website periodically to check for updates and read about changes, but the notification was also a reminder for me to check.

Thanks for the example script to check for update, I appreciate it.

@JoeSalmeri

Copy link
Copy Markdown

Ryan Yates (Ryan Yates (@kilasuit)) - That seems like a leap to assume a typical user that downloaded a software package from Install PowerShell 7 on macOS once is ever going to go back and check it again manually.

It isn't like there haven't been significant CVE's that have needed patching recently that put Linux and macOS users at risk.

Feels like the 'security is a priority' focus went out the window with this decision.

I agree, seems like a bad decision but at least there is a way we can restore the functionality with a few lines of code.

@kjwsge

kjwsge commented Oct 29, 2026

Copy link
Copy Markdown

This is a poor decision. Since I don't manage PowerShell through the Microsoft Store, I have no way of knowing if a patch is needed without the update notification. I don't understand why a perfectly normal function is being removed over a culture issue.

@kilasuit

Copy link
Copy Markdown
Collaborator

kjwsge I can give you some history behind this, and whilst it may seem like being removed over culture issues, there's much more to it than just that & has been on the teams mind to do this for some time as mentioned in this discussion

This feature, whilst well intentioned when it was added, has caused a number of unnecessary issues being raised in this repository, usually each month a new PowerShell version was released, and often multiple of them a month.

This was mostly because of PowerShell having been released here on GitHub, but not being instantly available from whatever place it was others wanted to install it from, whether that be via the Microsoft Store, Microsoft Update, packages.microsoft.com or via the operating system package managers like winget, apt, yum, dnf, snap etc so this lead almost every month to issues along the lines of PowerShell isn't available on xyz platform yet which mostly was noise and in many cases nothing that the team could do to change. There are still occasions where it's slower than about a week for the release to show up in those places, but usually there's nothing the team can do about that.

Then we'd have people (including myself) asking things like can the message in the notification be customised at all & please tell us how we actually update in the message & please tell us where and how did we install & which package type was it that we installed.

Also the amount of code that was required for this feature , as it was & without adding those additional requests, really wasn't worth it for the benefit it provided. Plus there had been many requests for this feature to be removed, due to it not being flexible enough, and for others, because it was completely useless to them.

Now balance this with that you can add into your PowerShell Profile as little as the below amounts of code which you can customise that'll tell you if there is a new PowerShell version to update to or not every time you start a PowerShell session.

using 1 liner and the gh cli tool if you use it

if((gh release list --repo PowerShell/PowerShell --json tagName --limit 1 --exclude-pre-releases | convertfrom-json).tagName.replace('v','') -notmatch $PSVersionTable.PSVersion.ToString()) {Write-Host 'New PowerShell version released' -ForegroundColor Green} else {Write-Host 'No New PowerShell version released' -ForegroundColor red}

or if the existing endpoint for the latest Stable release that the update notification used

$psstableTag = (irm https://aka.ms/pwsh-buildinfo-stable).ReleaseTag.replace('v','')
if ($psstableTag -match $PSVersionTable.PSVersion) {'No new PowerShell Release yet'}else{'There is a new PowerShell Release'}

or perhaps directly from the GitHub Releases RestAPI (which doesn't require auth token to pull data from) looking for the last release in the 7.6 or 7.7 releases but only output it if was in the last 15 days.

$days = -15
$psr = irm https://api.github.com/repos/powershell/powershell/releases
$76 = $psr | Select name,created_at,tag_name,html_url | where tag_name -Match '7.6' | select -First 1
$77 = $psr | Select name,created_at,tag_name,html_url | where tag_name -Match '7.7' | select -First 1
if ($76.created_at -gt (get-date).AddDays($days)) {
        Write-Output "New PSRelease 7.6 available: $($76.tag_name) - $($76.html_url)"
    }
if ($77.created_at -gt (get-date).AddDays($days)) {
        Write-Output "New PSRelease 7.7 available: $($77.tag_name) - $($77.html_url)"
    }

I am already making use of an adapted version of that last block of code in my profile that runs as a ThreadJob on startup that adds a section to my prompt if there are 1 or more new PowerShell Releases that I am interested in since I last let it check.

image

I hope from reading the above you can understand why the team had decided that they wanted to remove the Update Notification feature, & with it having this issue crop up now with localisation of the messages this feature provided, was no longer worth spending more engineering time or effort in fixing & why they ultimately chose to remove it now.

Yes there will be some that will miss this feature, there's there's many that likely won't miss that it's gone & many that even if they were making use of it, well now they get the chance to build themselves something similar, but more flexible & that they can customise however suits them best going forward & for a lot less code.

I would have preferred changing the message to say "this feature is getting removed in the next release" & then removing it, but the time frame between the 7.6.6 & 7.6.9 releases wouldn't have allowed to get that change in anyway.
image

I have proposed an update to the about_Update_Notification document for the 7.6 docs to include a section about the removal of this feature, as I don't think ripping the doc out straight away is the right approach, & that this feature can be easily replicated if needed pointing to the docs for the gh cli, GitHub Rest API & also to the metadata.json file in this repository that you can also query if you wanted.

@kwtobin

kwtobin commented Nov 3, 2026 •

Copy link
Copy Markdown

Now balance this with that you can add into your PowerShell Profile as little as the below amounts of code which you can customise that'll tell you if there is a new PowerShell version to update to or not every time you start a PowerShell session.

using 1 liner and the gh cli tool if you use it

if((gh release list --repo PowerShell/PowerShell --json tagName --limit 1 --exclude-pre-releases | convertfrom-json).tagName.replace('v','') -notmatch $PSVersionTable.PSVersion.ToString()) {Write-Host 'New PowerShell version released' -ForegroundColor Green} else {Write-Host 'No New PowerShell version released' -ForegroundColor red}

or if the existing endpoint for the latest Stable release that the update notification used

$psstableTag = (irm https://aka.ms/pwsh-buildinfo-stable).ReleaseTag.replace('v','')
if ($psstableTag -match $PSVersionTable.PSVersion) {'No new PowerShell Release yet'}else{'There is a new PowerShell Release'}

or perhaps directly from the GitHub Releases RestAPI (which doesn't require auth token to pull data from) looking for the last release in the 7.6 or 7.7 releases but only output it if was in the last 15 days.

$days = -15
$psr = irm https://api.github.com/repos/powershell/powershell/releases
$76 = $psr | Select name,created_at,tag_name,html_url | where tag_name -Match '7.6' | select -First 1
$77 = $psr | Select name,created_at,tag_name,html_url | where tag_name -Match '7.7' | select -First 1
if ($76.created_at -gt (get-date).AddDays($days)) {
        Write-Output "New PSRelease 7.6 available: $($76.tag_name) - $($76.html_url)"
    }
if ($77.created_at -gt (get-date).AddDays($days)) {
        Write-Output "New PSRelease 7.7 available: $($77.tag_name) - $($77.html_url)"
    }

I appreciate the background but this was handled poorly. If the feature was going to be removed that should have been announced in advance, and only after documentation on how to enable notifications within your profile was added to the installation learn pages and mentioned in the release notes.

I'm not sure how a typical user would find any of this information and the recommended installation method for macOS users still leaves them with no obvious way to ever know they're on an outdated version. https://learn.microsoft.com/en-us/powershell/scripting/install/install-powershell-on-macos?view=powershell-7.6

Then again, the documentation also points users to 7.6.6 and the referenced Changelog stops at 7.6.4.

How to install PowerShell on macOS

@kilasuit

Copy link
Copy Markdown
Collaborator

kwtobin - yeah it could have been handled better. I did note about the outdated versions being referenced on the Install PowerShell 7 on macOS page, but could you clarify what you mean about or point me to where the referenced Changelog stops at 7.6.4. may be as I couldn't find it

@kwtobin

kwtobin commented Nov 3, 2026 •

Copy link
Copy Markdown

Ryan Yates (@kilasuit) - Sorry, I should have been more clear on that. The What's New in PowerShell section on the sidebar, and particularly, What's New in PowerShell 7.6 (https://learn.microsoft.com/en-us/powershell/scripting/whats-new/what-s-new-in-powershell-76?view=powershell-7.6) links to https://github.com/PowerShell/PowerShell/blob/master/CHANGELOG/7.6.md.

New features and changes released in PowerShell 7.6
GitHub
PowerShell for every system! Contribute to PowerShell/PowerShell development by creating an account on GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Backport-7.6.x-Done Backport-7.7.x-Done CL-General Indicates that a PR should be marked as a general cmdlet change in the Change Log

Projects

None yet

Development

Successfully merging this pull request may close these issues.

PowerShell can crash on startup when displaying the update notification under zh-Hans due to negative PadRight width

7 participants