Upgrade one package intentionally. First inventory available updates, identify the installed and available versions, read relevant release information, protect current work, upgrade the exact package, and verify behavior.
Inventory without changing
Run from a standard PowerShell session:
winget list --upgrade-available
Microsoft documents this filter in
winget list.
The result can include software originally installed by other means, and version
detection may be incomplete.
Do not begin with a bulk upgrade. Choose one course-required, noncritical tool whose interruption you can tolerate.
Inspect identity and versions
Record exact package ID, source, installed version, and available version:
winget list --id Vendor.Package --exact
winget show --id Vendor.Package --exact
Review official release notes when the update could change course commands, extensions, file formats, or dependencies. Confirm the course does not require an older version.
Prepare recovery
Before changing:
- close the application and save work;
- commit or back up relevant project files;
- record configuration and extensions when material;
- know how the application is repaired or reinstalled;
- note whether a restart may interrupt work; and
- check institution-managed maintenance policy.
WinGet is not a system restore plan. An installer may not support downgrading.
Upgrade the exact package
winget upgrade --id Vendor.Package --exact
The current WinGet upgrade documentation describes available options and selection behavior. Read the live help on the machine:
winget upgrade --help
Some installers request elevation. Approve only after confirming identity and need. Institution-managed devices may block the operation or manage updates centrally; do not bypass restrictions.
Verify after change
Open a new terminal and check:
- WinGet’s installed version.
- The tool’s own version.
- One normal course workflow.
- Relevant extensions or configuration.
- Project tests or builds affected by the tool.
- Restart requirements and recorded errors.
If verification fails, stop new changes. Preserve logs, describe expected and actual behavior, and use the vendor’s or institution’s approved recovery route.
Bulk upgrades are a separate decision
winget upgrade --all is convenient but expands scope. Many simultaneous
changes make failures harder to attribute and may restart applications or
request multiple agreements. Use it only with an understood maintenance plan,
appropriate backups, time to test, and authorization.
Common mistakes
- Updating immediately before an assignment deadline.
- Ignoring the exact package ID or source.
- Assuming every listed version is comparable.
- Elevating the whole terminal unnecessarily.
- Upgrading all packages without a checkpoint.
- Reporting success without running the actual tool.
Do this now
Inventory upgrades on an authorized device. Select one low-risk approved tool, record versions and recovery, upgrade by exact ID if permitted, and run its course-relevant verification.
Log what you learned
Record only:
- Result: What did the action produce?
- Evidence: What observation, test, or source supports that result?
- Next action or unresolved question: What should happen next?
Next, practice ten PowerShell operations in a disposable folder.