Windows Package Manager 1.29.380 ships with a big version number and one merged PR
The latest WinGet servicing release skips 90 build numbers but delivers just a single change, carried backward from the v1.30 preview line.
Microsoft released Windows Package Manager v1.29.380 today. If you're keeping score, it's largely a number on a label. The build ticks forward 90 spots from the previous stable tag, and exactly one pull request merged in that gap. That's the whole story for the new release. Everything else is the v1.29 toolkit Microsoft shipped back in late August.
Here's how WinGet's numbering works. The third component tracks an internal build calendar rather than a count of merged changes. So jumping from 1.29.290 to 1.29.380 doesn't mean nine times the work went in. It means Microsoft stamped a newer date on a feature-frozen branch and has been parking maintenance fixes there ever since.
That makes 1.29.380 a textbook servicing release. Not exciting. But honest about what it is.
Active development has already shifted to v1.30, which carries the very same path-rooting fix this release bundles. So this is really a backward-port of stability fixes, not a forward-looking feature drop.
The full v1.29 toolkit rides along
The real substance of this release isn't the new change. It's everything v1.29 already brought, and it's a solid stack to hand over.
Source Priority is the standout. You can assign numbers to package sources so the ones you actually care about sort to the top. It applies to search results and, more usefully, to installs. Run a private feed and WinGet just picks the highest-priority source instead of nagging you with "multiple packages were found" every other command.
Then there's --no-progress. It kills progress bars and spinners across all commands, and it wins over the visual.progressBar setting, so scripts and CI/CD pipelines get clean output whether they like it or not.
The MCP server got two upgrade-aware parameters too. Flip upgradeable or upgradeOnly, and your AI coding agent can actually update installed packages rather than just inventory them. "What can I patch?" becomes "Go ahead and patch them all."
Keep in mind that the PowerShell module now reads GH_TOKEN or GITHUB_TOKEN automatically. That quietly lifts the GitHub API rate limit that used to chew through pipelines before they finished.
The one new change, and what it means for security
PR #6467 normalizes relative paths into absolute ones. Authored by JohnMcPMS and reviewed by yao-msft, it touched 10 files and was cherry-picked from the v1.30 preview, where the original work came from contributor florelis. In short, WinGet now knows exactly where it's reading and writing, and won't resolve paths against some random working directory. Small correctness fix, faint whiff of security, since unrooted relative paths can land somewhere unexpected.
The bundled changes carry more weight up the supply-chain stack. WinGet's embedded signtool now supports an optional RFC 3161 timestamp server through a new TimestampServer property, so packages signed with an expiring certificate stay trustworthy after that certificate lapses. Signing infra tends to rot on schedule, and this keeps the trust chain intact while you rotate certs.
A few other fixes round it out: winget export works with hidden destination paths, winget source reset now resets instead of deleting sources, and a crash tied to the experimental Resume feature under --disable-interactivity is gone.
But unlike v1.29.290, which folded in two internal privilege-escalation fixes, 1.29.380 ships no authentication or attack-surface patches. Its security value sits in integrity and reliability, not in closing a hole.
And the MSIX bundle? It's 217 MB. For a package manager whose whole job is installing tiny apps, that's a lot of wrapper to shuffle around. That's Microsoft's packaging for you, and you can't do much about it anyway.
Where you stand
If WinGet self-updates, you're probably already on something close. Run winget upgrade --id Microsoft.DesktopAppInstaller to grab the latest, or pull the .msixbundle straight from GitHub Releases. Supported platforms span Windows 10 1809 and up, Windows 11, and Windows Server 2025+.
Want newer features like the --ignore-unavailable flag? Track the v1.30 preview instead. If you'd rather not chase previews, 1.29.380 is a complete, production-ready build sitting quietly on the stable line.
Head here to the GitHub release.
