At the end of last month, I blogged about an interesting issue: when you used WinGet to upgrade PowerShell (in PowerShell) that operation would complete, but the screen wouldn’t update properly. As I reported, it showed cancelled and required opening a new PS session to see the current, upgraded version number. No more: now, MS has WinGet upgrade PowerShell working as it should be. See the lead-in graphic for visual proof.

If WinGet Upgrade PowerShell Working, Then What?

No more weirdness in the self-upgrade process, I guess. The lead-in graphic shows that PowerShell updated the initial session window to match the current version (7.3.6) with the version number at the top of the that window. Indeed, I’m forced to *SWEAR* it said 7.3.5 when I started, and appeal to the 2nd line of the WinGet upgrade output because I didn’t think to capture “before” and “after” screencaps. LOL, it didn’t occur to me that the developers would rewrite the terminal window to update the version number. But they did!

I contacted Demitrius Nelon, Team Lead for WinGet at MS to report this weirdness, which he confirmed for me. What he didn’t tell me was that they fixed this in the 7.3.6 release. But its behavior, as shown in the lead-in graphic, speaks for itself. Good stuff and thanks, people: good job.

Got It on Another PC!

I went to upgrade another PC and *DID* capture the initial screen showing 7.3.5 at the top. No more swearing: here’s the screen before the 7.3.6 upgrade completes so you can see the old version number in its top line.

See!? There’s the old version number before the 7.3.6 update completes. It’s like magic!

Note added 7/19: looks like this capability (no cancelled and updating version number) may only be in Windows 11. When I updated my sole remaining Windows 10 physical PC this morning, the cancelled message recurred as in my earlier blog post on this subject. Go figure!