Upgrade an installed App

[denelon]

As a user I want to be able to use winget to install the most current version of a currently installed program so I don't have to go find it.

Experimental Feature
winget upgrade - displays installed packages with an available upgrade.
winget upgrade -? - displays help for the upgrade command.
winget upgrade --all - upgrades all packages with an available upgrade.
winget upgrade <package> - upgrades the specified package.

Note: upgrade depends on list also being enabled.

winget features - displays all experimental features and their status
winget settings - launches settings.json to configure settings like experimental features

Edited: experimental status

[denelon]

If the command is executed without any parameters, it could update "everything" installed by winget.

[jantari]

I would strongly suggest we stick to the verbs familiar from apt:

winget update #Refreshes the repositories
winget upgrade #Actually updates apps

One of the very confusing things about package managers are the different syntaxes they use. I don't
speak for everyone, but I genuinely find pacman, yum and dnf confusing. zypper is ok.

apt is popular and - imo - easy to understand. Introducing update as a command that actually starts updating apps would break muscle memory I believe

[Rican7]

I would strongly suggest we stick to the verbs familiar from apt:

winget update #Refreshes the repositories
winget upgrade #Actually updates apps

Yea, agreed. This is what Homebrew (brew) uses too, so even more prior-art here.

[khobbits]

I think we can probably get away from the requirement to have a command to to 'refresh the repositories'. It feels like a little step backwards in time having to refresh apt, compared to yum. Surely the tool can work out if the repositories require updating automatically?

If we need to operate in a cached/offline mode that shouldn't that extreme edge case require a parameter rather than be the default?

As to which verb, update/upgrade? Why not allow the use of both?

[despotak]

I agree with @khobbits that a "refresh the repos" commands is a backward step. I really hope that winget does not need to manually refresh the repositories before an update.
On the other hand, I see @jantari's and @Rican7's PoV. Probably then the solution is somewhere in the middle. Disregard winget update and use winget upgrade as the default command.

Another solution might be that update is an alias for upgrade (or via versa).

[seanfisher]

Yea, agreed. This is what Homebrew (brew) uses too, so even more prior-art here.

Agree with @khobbits and @despotak and just wanted to pitch in that Homebrew automatically updates when you brew install, brew upgrade or brew tap (see the man page and search for AUTO_UPDATE).

Another solution might be that update is an alias for upgrade (or via versa).

This seems like the best solution to me.

[lordcheeto]

While it may not be the right option for winget, apt separated update and upgrade steps for a reason. Besides not having to update the package list for every operation, it enables it to update the package list on a schedule, run security upgrades automatically, and give notifications in the MOTD when you log in about other packages that can be upgraded, without actually upgrading them.

Chocolatey does this with a separate outdated command.

[bc3tech]

glad to see I'm not the only one praying for the love of God keep the update vs upgrade complexity out of Windows. Chocolatey's been just fine w/o it.

[jaydn]

update / upgrade is there for a reason. Perhaps you just want to check how much is going to be upgraded - or check the package list for anything that looks risky and do it later? Would be a step backward to not be able to do this imo

[0x49D1]

Does winget work kind of chocolatey now? Chocolatey has local repository of installed packages, so that it can update them in case I want to all in 1 batch. But in case I'm upgrading already installed package from it's update system - there will be no problem. For now winget seems very basic, there is no command to see the already installed packages, so I assume that maybe it just downloads the installers and runs them with default parameters... One of the main reasons of package management for me is also security, I've not found any mentions of how package is checked before it's added to the repository of winget.

[sschuberth]

So how about all of these (with upgrade being an alias for update as already suggested):

• winget update to update meta-data and upgrade all packages
• winget update <package> to update meta-data and upgrade only <package>
• winget update --only-meta-data to update meta-data only and upgrade no packages
• winget update --no-meta-data to upgrade all packages based on local (not updated) meta-data
• winget update --no-meta-data <package> to upgrade only <package> based on local (not updated) meta-data

I believe it's also important to be able to list all available updates without actually installing them, but that probably does not require a separate command and can simply be accomplished by a prompt before the actual update / upgrade.

[sschuberth]

What's probably way more difficult than implementing the update command itself is the logic to automatically get the version of programs in order to determine if there is an update available. Many installers / executables do not maintain their embedded "File version" / "Product version", and there simply is no unified way how Windows programs announce their updates or check for updates themselves.

Edit: Looks like I misunderstood how winget is supposed to work. It does not even try to determine whether upstream has released a new version, but solely relies on its own meta-data which has to be maintained for each version of a package.

[crumdev]

What's probably way more difficult than implementing the update command itself is the logic to automatically get the version of programs in order to determine if there is an update available. Many installers / executables do not maintain their embedded "File version" / "Product version", and there simply is no unified way how Windows programs announce their updates or check for updates themselves.

Edit: Looks like I misunderstood how winget is supposed to work. It does not even try to determine whether upstream has released a new version, but solely relies on its own meta-data which has to be maintained for each version of a package.

The manifest yaml file that a company has to provide includes the version number in it. This should be easy to find then. Better yet it seems that the way everything is structured that the manifest name itself is the version number under the application folder.

https://github.com/microsoft/winget-pkgs/blob/master/manifests/Anki/Anki/2.1.26.yaml

https://github.com/microsoft/winget-pkgs/tree/master/manifests/Adobe/Brackets

[bc3tech]

update / upgrade is there for a reason. Perhaps you just want to check how much is going to be upgraded - or check the package list for anything that looks risky and do it later? Would be a step backward to not be able to do this imo

which is why chocolatey added outdated (has already been proposed here). update/upgrade is confusing to literally every person unfamiliar with Linux.

[twindan]

Shouldn't that just be another switch to "show what you are going to do"?

For instance, apt-get has a switch "-s/--simulate/--just-print/--dry-run/--recon/--noact" that just reports what it's going to upgrade, but doesn't actually do it.

[bc3tech]

Shouldn't that just be another switch to "show what you are going to do"?

For instance, apt-get has a switch "-s/--simulate/--just-print/--dry-run/--recon/--noact" that just reports what it's going to upgrade, but doesn't actually do it.

And chocolatey has

     --noop, --whatif, --what-if
     NoOp / WhatIf - Don't actually do anything.

but IMO that should be filed as another issue if ppl want it. I've never used the feature.

[i255d]

I have to change my OS to the insider version to try this? I don't see what to do with this block of code that I downloaded from Github???

[cnshenj]

While it may not be the right option for winget, apt separated update and upgrade steps for a reason. Besides not having to update the package list for every operation, it enables it to update the package list on a schedule, run security upgrades automatically, and give notifications in the MOTD when you log in about other packages that can be upgraded, without actually upgrading them.

Chocolatey does this with a separate outdated command.

Except some savings in network traffic and server computing power, all the benefits you mentioned can be achieved without an offline cache, or at least without an explicit command to update offline cache. Assuming network data usage is not a problem, some benefits are actually burdens. For example: there is no need to update the package list on a schedule because local winget always accesses the online package list which is always up-to-date.

An update command that actually updates packages with a --dry-run switch is enough. Internally, winget can maintain certain local cache for performance optimization, but there is no need to expose that to users.

[catthehacker]

I have to change my OS to the insider version to try this?

No

I don't see what to do with this block of code that I downloaded from Github???

Please read Installing the client

If you are talking about the --update feature, it's not available yet.

[i255d]

I have to change my OS to the insider version to try this?

No

I don't see what to do with this block of code that I downloaded from Github???

Please read Installing the client

If you are talking about the --update feature, it's not available yet.

I have read Installing the client, it doesn't give any directions. It says I have to get on the insider program, which means, as far as I know, I have to change my OS to the insider addition, which is a problem on a computer I am using every day. There is no executable in the downloaded get hub. When I try to use Windows Store, it says installed on this pc, but it gives no info on how to use it. I have tried rebooting my pc, and it the winget command still doesn't work in PowerShell or from the command prompt. Why can't I just download the app, and put the executable in the path statement and it works???

This is installing a different addition of my OS???

Follow these steps to download Insider Preview:
Verify which edition of Windows 10 you need to download.
See the “Select Edition” section below for details
If you’re not sure which ring your device is opted into, verify in the Settings Page:
Settings > Update & Security > Windows Insider Program
Read the system requirements.
Click one of the Download links on this page to download an ISO file that you can use to install the preview.
Review the instructions below for doing an in-place upgrade (keeps your files and applications) or a clean install (erases/removes all data from your device).

That is to much!!!!

[Shinigami92]

@i255d just use the manual way:
https://github.com/microsoft/winget-cli/blob/master/README.md#manually-update

Download from release and double click to install. If this is to difficulty for you, pls don't install preview software on your machine!

And now pls stop to ask off-topic questions. I have subscribed to this issue and getting emails for every new message.

[ChristianGalla]

A few thoughts transferred from #263, because I think this should be part of the discussion and implementation of this feature:

Sometimes there are breaking changes or bugs between new software versions, and it is required to stick to an older version. I think it should be possible to configure allowed version ranges for updates. For an example see semantic versioning in NuGet or npm.

Some programs (like browsers) already have a build in update service.
I think when winget's update is called, no updates should be installed for programs that are already updating themselves. Maybe such programs should only be updated via winget if a force parameter is set? Maybe the yaml file should have a new parameter to disable winget's update and / or a setup parameter to disable the installation of a build in update service?

[bc3tech]

A few thoughts transferred from #263, because I think this should be part of the discussion and implementation of this feature:

Sometimes there are breaking changes or bugs between new software versions, and it is required to stick to an older version. I think it should be possible to configure allowed version ranges for updates. For an example see semantic versioning in NuGet or npm.

Some programs (like browsers) already have a build in update service.
I think when winget's update is called, no updates should be installed for programs that are already updating themselves. Maybe such programs should only be updated via winget if a force parameter is set? Maybe the yaml file should have a new parameter to disable winget's update and / or a setup parameter to disable the installation of a build in update service?

choco pin

[denelon]

@YsHaNgM I think you may have uncovered a bug with upgrade related to PowerToys. I was able to see the same thing you reported.

We're still working on mapping entries in the community repository against what is represented in "Add/Remove Programs". Microsoft.WindowsTerminal and Microsoft.WindowsTerminalPreview have both worked when I tested by explicitly installing a previous version and then running winget upgrade.

[YsHaNgM]

I think this need to have a higher priority to fix since store apps are easy to upgrade via store's auto update. To maintain non-store installed apps is the main point of using a package manager. But the essential feature is not working.

[catthehacker]

But Windows Terminal (and Preview) are both available out of store.

[denelon]

I did the test with the store disabled to make sure the scenario works with the default source. We are looking into what happened with PowerToys. #752

[dreaddr]

Hoping to not see update to refresh repos, and to see winget sync to sync repos manually if need be, ideally this is done automatically. (Perhaps winget sync --off to disable auto syncing and sync --on for enabling it, while just running winget sync will manually do so.)

Totally fine with winget update and winget upgrade being alias, but perhaps have winget upgrade ask the user "Did you intend to update all packages? y/n" (or something similar perhaps) when run.

[denelon]

The current behavior for upgrade supports winget upgrade --all to upgrade all packages.
We don't have PIN in place yet to ensure one doesn't upgrade a package that they might not want upgraded. The default upgrade behavior may change once PIN has been implemented.

[Trance-Paradox]

Winget upgrade is not working for me

[denelon]

@Trance-Paradox you will need to ensure the "upgrade" experimental feature is enabled. Check winget features to see that it has been enabled. Use winget settings to enable experimental features. If Visual Studio Code is your default editor, the JSON $schema will provide help with syntax and settings.

[Trance-Paradox]

@Trance-Paradox you will need to ensure the "upgrade" experimental feature is enabled. Check winget features to see that it has been enabled. Use winget settings to enable experimental features. If Visual Studio Code is your default editor, the JSON $schema will provide help with syntax and settings.

I have it enabled.
Also newer versions of programs are available
Here is an example

[denelon]

@Trance-Paradox you will need to ensure the "upgrade" experimental feature is enabled. Check winget features to see that it has been enabled. Use winget settings to enable experimental features. If Visual Studio Code is your default editor, the JSON $schema will provide help with syntax and settings.

I have it enabled.
Also newer versions of programs are available
Here is an example

#752 Upgrade doesn't work for several packages

[pratikpc]

@denelon why not just winget upgrade *?

Instead of --all?

[denelon]

@denelon Demitrius Nelon FTE why not just winget upgrade *?

Instead of --all?

We haven't implemented "wild cards" like * or ? yet. When we tackle that we will likely have the changes cascade through all of the commands.

[emass-sec]

winget upgrade doesn't seem work for many or any packages yet. My test was with VideoLAN.VLCNightly

[eidylon]

I've had it be spotty. On my last attempt it told me there were three updates...

Id                                             Version      Available    Source 
--------------------------------------------------------------------------------
ArduinoLLC.ArduinoIDE                          1.8.42.0     Latest       msstore
HaukeGtze.AutoHotkeypoweredbyweatherlights.com 1.1133.8.0   Latest       msstore
Microsoft.SQLServerManagementStudio            15.0.18369.0 15.0.18384.0 winget 

But when I try to upgrade them, they have varying results and success.

Arduino IDE:

C:\>winget upgrade ArduinoLLC.ArduinoIDE
Found Arduino IDE [ArduinoLLC.ArduinoIDE]
This package is provided through Microsoft Store. winget may need to acquire the package from Microsoft Store on behalf of the current user.
Verifying/Requesting package acquisition...
Verifying/Requesting package acquisition success
Starting package install...
No applicable update found.

AutoHotKey successfully installed the update yesterday. Though today it has the same results as the Arduino IDE.

Sql Server SSMS:

C:\>winget upgrade Microsoft.SQLServerManagementStudio
No installed package found matching input criteria.

So it does work sometimes (e.g. AutoHotKey yesterday), but it is not reliable yet.

[Karl-WE]

it can also cause issue or duplicates depending the installer but that's more of a natural reason
Example:
7zip 19.00 installed as msi
instal 77zip 20.x beta via winget will cause a duplicate in settings > apps while files are effectively overwritten.

[arcmodo]

I've used winget upgrade --all multiple times to try and upgrade PowerShell and Calibre, but they aren't actually upgrading despite the results shown below. It downloads the updated installer and runs it, but the installers then disappear and don't actually do the upgrade. Running the upgrade check again shows the same initial results. These packages were installed before the latest version. Do I need to install them again with the new version for the upgrade to work moving forward? I did see a comment above that someone needed to install an older version and then used upgrade.

C:\Users\x>winget upgrade
Name Id Version Available Source

PowerShell Microsoft.PowerShell 7.0.4.0 7.1.3 winget
calibre calibre.calibre 5.6.0 5.17.0 winget

C:\Users\x>winget upgrade --all
Found PowerShell [Microsoft.PowerShell]
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://github.com/PowerShell/PowerShell/releases/download/v7.1.3/PowerShell-7.1.3-win-x64.msi
██████████████████████████████ 95.0 MB / 95.0 MB
Successfully verified installer hash
Starting package install...
Successfully installed

Found calibre [calibre.calibre]
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://calibre-ebook.com/dist/win64
██████████████████████████████ 124 MB / 124 MB
Successfully verified installer hash
Starting package install...
Successfully installed

C:\Users\x>winget upgrade
Name Id Version Available Source

PowerShell Microsoft.PowerShell 7.0.4.0 7.1.3 winget
calibre calibre.calibre 5.6.0 5.17.0 winget

[denelon]

@jrennemeyer we still have a couple of additional pieces of work to address upgrades. One of them is in the next release (checking all manifests for ProductCode), and the other will be in a future release (installers of one type inside another). I've also been gradually making changes to manifests so that the entries inside of Add / Remove Programs match the PackageName and Publisher.

[spragginsdesigns]

I agree with @khobbits that a "refresh the repos" commands is a backward step. I really hope that winget does not need to manually refresh the repositories before an update.
On the other hand, I see @jantari's and @Rican7's PoV. Probably then the solution is somewhere in the middle. Disregard winget update and use winget upgrade as the default command.

Another solution might be that update is an alias for upgrade (or via versa).

I know this is a year old, but I agree. I always have to run sudo apt update -y && sudo apt upgrade -y in Linux distros, and it feels redundant and backward for Winget to do this.

I would love to join this discussion. I will look into what I can do to support and update this repo in my spare time and contribute to something Windows should have had long ago. I am very excited to see this new feature and have everyone at work using it now.

I wish the update/upgrade feature worked adequately right now, though. I will see what I can do on my end to fix/update this issue.

[denelon]

@Atmosphere9999 the default "Time To Live (TTL)" for the cache is five minutes. It is configurable in settings. As long as the machine has access to the PreIndexed source package, it should refresh on it's own when any command depending on the source is executed.

Most of the challenges related to the update command are related to installers with different metadata in the manifest and the entries the installers add to Add / Remove Programs. We have several work items to improve matching the meta-data and the associated experience with winget upgrade.