Think about it. When a program needs an update, sometimes what’s doing the update and what’s getting the update may be related. This gets interesting. Windows itself is a pretty good example. This explains why reboots are required to install  an OS, and often when updating same. Simply put, the pieces being working on cannot also do the work on themselves in many cases. Applications, apps, and so forth can also fall prey to the same things (think about installing an installer). Thus, avoiding Windows self-update traps is something of a balancing act.

Example: Avoiding Windows Self-Update Traps

I saw a great example of an artful dodge around this problem yesterday, as I was using Winget to update Windows Terminal (WT). Take a look at the lead-in graphic. It shows the WT update progress. Note that the last instruction at the end of that process reads:

Restart the application to complete the upgrade.

That’s exactly the kind of maneuver that’s necessary. It allows the currently running code for a program (or OS) stop running. Then, the newly-updated or installed code for the same program (or OS) can take over and start doing its thing.

Counter-Example: PowerShell

Back in June, I wrote a blog post here entitled WinGet Upgrade PowerShell Shows Cancelled. It shows what can — and sometimes still does — happen when the tail end of the installation process fails to complete and exit cleanly. I know the PS team is working on this, but this shows that self-updates do pose occasionally tricky problems.

I’m glad to see the WT take the high road and suspend the final steps of install or upgrade until it’s safe to do so. I’ll be gladder still when the PS team eventually follows suit (as I’m sure they will). In the meantime, I did find a workaround: if you open a Command Prompt session and run the winget PS upgrade there, no “cancelled” (or other error messages) result. Good enough for me, for now!