Powershell: Powershell version nags are overly aggressive

[anaisbetts]

Please don't nag users every time they open a shell for a 0.0.1 release - if you pop this dialog every time you make the smallest release, and you (as you should!) make many small incremental releases, this will effectively mean that the vast majority of your users are being constantly harassed to upgrade, all the time.

A few solutions:

• Lower the user's time / attention "cost" of upgrading, so that the cost of upgrading is a single "do it" click or copy-paste command (Upgrade-PowerShell command maybe?)

• Make the nag proportional to the size of the update - 0.0.1 releases shouldn't get the same real-estate as "Check out PowerShell 8.0!"

• Make the nag only show up once per day instead of every single invocation

[rjmholt]

0.0.1 releases shouldn't get the same real-estate as "Check out PowerShell 8.0!"

This is interesting, since patch releases often have security patches in them (particularly from .NET). In this sense, patch releases are much more important than major version releases to the people seeing them. To this end, I would imagine there are many users who are on PS 7 LTS who don't want a notification for PS 7.1 or 8, but who really need to see one for PS 7.0.1. I believe this is exactly how the LTS update channel is configured to function currently.

I think the assumption in the issue here is that bigger version increment means that there's more goodness means that you should be more likely to upgrade. But really it's the opposite. Smaller version increment means more relevant to your current installation means you have more to gain and less to lose by upgrading.

The version update notification isn't marketing, it's PowerShell's current solution to the update problem given that its installation is managed in different ways across different platforms.

[rkeithhill]

You can disable the update check by setting a user or system environment variable called POWERSHELL_UPDATECHECK to 0 but I wouldn't recommend doing that unless this really bothers you. :-)

[rkeithhill]

pop this dialog every time you make the smallest release

To put this into perspective, if you were on the stable 6.2.0 release (3/28/2019), and these messages popped up for 6.2.x, you would have gotten 5 notifications in the past ~15 months. That's an average about one upgrade notification every 3 months. That is, of course, assuming you upgrade. :-)

[rjmholt]

Make the nag only show up once per day instead of every single invocation

Yeah I thought we already did this. /cc @daxian-dbw @SteveL-MSFT

so that the cost of upgrading is a single "do it" click or copy-paste command (Upgrade-PowerShell command maybe?)

I think we all want that, but it's currently not easy to solve. Unfortunately I don't know enough about the issues at play to conjecture (@joeyaiello might). On macOS and Linux package managers are how we resolve this. On Windows, MSIX installations in the Store also resolve this. But MSI and zip installations have no package management concept. The diversity of installation vectors certainly makes an Update-PowerShell command more complex. I believe there is a will for a solution here though.

[iSazonov]

Yeah I thought we already did this

We have a code only for delaying the check in network. (See CheckForUpdates() method.)

The diversity of installation vectors certainly makes an Update-PowerShell command more complex.

Interesting, how does VS Code implement this?

[rjmholt]

how does VS Code implement this?

Ah that's a good question. It basically presumes you installed with the MSI. On macOS and Linux it just reminds you; it won't try and run a package manager update for you on macOS it will run homebrew, and I’m not sure about Linux. But I don't think it's configured to work with an MSIX or .pkg installation. And detecting how you installed after installation is the hard part

[vexx32]

On macOS and Linux it just reminds you; it won't try and run a package manager update for you.

On my Mac, it will happily go off and run Homebrew to do the update for me, in my experience. 🙂

[iSazonov]

So VS Code knows how it was installed.

And detecting how you installed after installation is the hard part

We could add a resource per package type. This could be an empty file in home folder.
It would be great UX for personal installations but for Enterprises this should be disabled.

[rjmholt]

On macOS and Linux it just reminds you; it won't try and run a package manager update for you.

On my Mac, it will happily go off and run Homebrew to do the update for me, in my experience. 🙂

Oh! You’re quite right. Not sure about Linux, since root is needed.

[xtqqczze]

IMO the version update notification should not appear until at least 24 hours after release.

[marcusl]

If it's contains a security fix, the notification should mention that.

Currently it looks like "hey, we fixed a typo! check it out.". That's not the intention maybe?

Also, lowering the effort to upgrade, at least on Windows would be nice, like a one-liner that's shown in the notification.

Love your work though! :)

[nzain]

Imho, simplifying upgrades (regardless of OS and the installation source) is important.

Maybe it would be sufficient to help people create their own upgrade script? I know there is an Install-Powershell.ps1 at https://aka.ms/install-powershell.ps1 but it did not upgrade my installation, just unzip the latest package into %appdata%\Microsoft\powershell. Maybe it is easier to create a dedicated website with upgrade strategies (and scripts) for each type of install.

[SteveL-MSFT]

The bar for servicing updates is high. We don't take trivial fixes to avoid risk of regression. There should only be fixes that are security, compliance, or customer blocking issues. This RFC describes the intent and design in detail and ways to disable.

Auto-update is something I would love to have, but is very difficult to solve whether because it requires root or due to open file handles (and requiring elevation) on Windows. However a cmdlet like Update-PowerShell where we make it easier to install an updated version the same way you originally installed it (which means potentially popping up the MSI installer) seems feasible.

[xtqqczze]

It would be good if we could ensure a new Chocolatey package is available before the version nag appears. I previously suggested we could delay the notification by 24 hours to allow for this.

Ideally we would have automatic Chocolatey releases from a pipeline (#12673). /cc @DarwinJS

[anaisbetts]

The bar for servicing updates is high. We don't take trivial fixes to avoid risk of regression. There should only be fixes that are security, compliance, or customer blocking issues. This RFC describes the intent and design in detail and ways to disable.

This is useful to know, but users don't understand that because it's very much contrary to how most software treats version numbers - nobody sees an 0.0.1 increase and thinks "Wow, I should definitely get that, it's almost certainly security related!!!"

If this is the case, PowerShell needs to call out security updates differently than "We added new stuff" releases, and do things to educate users about how PowerShell uses version numbers Differently than most projects

[vexx32]

PowerShell uses version numbers according to the widely established and commonly recognised semver aka Semantic Versioning.

It's not uncommon by any stretch of the imagination, though its use in the Windows / Microsoft ecosystem is pretty rare.

[SidShetye]

Is there any way to disable the nags? Also, IMHO, the upgrades should be coming through windows update.

[vexx32]

Pwsh is not (yet) a Windows component, so will not be updated via Windows update until that changes. The support lifecycle is currently also vastly different to Windows' own.

As for disabling them, one option is to start pwsh with the -NoLogo parameter.

[doctordns]

Is there any way to disable the nags? Also, IMHO, the upgrades should be coming through windows update.

Updates via Windows Update would be great, but that is not going to come any time soon.

In the meantime, what is the problem with having an option in the configuration.json file to tell PWSH NOT to check for new versions?

[sysopsdev]

Can someone please demonstrate how to PERMANENTLY disable this?

[System.Environment]::SetEnvironmentVariable("POWERSHELL_UPDATECHECK", 0)

This did not work. Nor did

$Env:POWERSHELL_UPDATECHECK = 0
$Env:POWERSHELL_UPDATECHECK = 'Off'

It is continuously popping up. With the colorscheme I have set it's most unpleasant to look at. I know devs tend to complain about frivolous garbage, and I'm not even asking you to change it. I just want to know how to disable this permanently. The solutions above are not working.

[vexx32]

You need to set it either in the current user or machine scope. By default the SetEnvironmentVariable method only sets the variable in the current process.

[Environment]::SetEnvironmentVariableTarget("POWERSHELL_UPDATECHECK", 0, 'User') # or 'Machine' for all users

[sysopsdev]

You need to set it either in the current user or machine scope. By default the SetEnvironmentVariable method only sets the variable in the current process.

[Environment]::SetEnvironmentVariableTarget("POWERSHELL_UPDATECHECK", 0, 'User') # or 'Machine' for all users

Thank you! ✌

[daxian-dbw]

what is the problem with having an option in the configuration.json file to tell PWSH NOT to check for new versions?

You won't want powershell to parse the config file at the startup time, given that we already have perf issue in startup.
As @vexx32 showed above, you can set the environment variable POWERSHELL_UPDATECHECK to 0 at either the current user or machine scope to disable the update notification.

[doctordns]

what is the problem with having an option in the configuration.json file to tell PWSH NOT to check for new versions?

You won't want powershell to parse the config file at the startup time, given that we already have perf issue in startup.
As @vexx32 showed above, you can set the environment variable POWERSHELL_UPDATECHECK to 0 at either the current user or machine scope to disable the update notification.

Given that the json file us already loaded and parsed, would there really be that much overhead involved vs reading an Environment variable? I would prefer to see more in json and less in environments variables.

[daxian-dbw]

Today, there is no powershell.config.json file ship with PowerShell by default for Linux and macOS. On Windows, it's unfortunate that we have a default config json file that contains WindowsPowerShellCompatibilityModuleDenyList and ExecutionPolicy, but both defaults potentially can be moved to code to avoid having a default config json file at all.

[msftbot[bot]]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.