Upgrade an installed App

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

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

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

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.

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?

Robert (KHobbits) (@khobbits)

I agree with Robert (KHobbits) (@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 Trevor N. Suarez (@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).

Robert (KHobbits) (@khobbits)

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

Agree with Robert (KHobbits) (@khobbits) and Christos Despotakis (@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.

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.

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.

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

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.

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.

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.

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

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.

Surya Karmakar (@Trance-Paradox)

Surya Karmakar (@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

Surya Karmakar (@Trance-Paradox)

Surya Karmakar (@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

Demitrius Nelon (@denelon)

Demitrius Nelon (@denelon) why not just winget upgrade *?

Instead of --all?

Demitrius Nelon (@denelon)

Demitrius Nelon (@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.

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

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.

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.

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

@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.

Robert (KHobbits) (@khobbits)

I agree with Robert (KHobbits) (@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 Trevor N. Suarez (@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.

@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.

Navigation Menu

Repository navigation

Upgrade an installed App #120

82 remaining items

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

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Upgrade an installed App #120

Description

Activity

denelon commented on May 11, 2020

jantari commented on May 19, 2020

Rican7 commented on May 19, 2020

khobbits commented on May 19, 2020

despotak commented on May 19, 2020

seanfisher commented on May 19, 2020

lordcheeto commented on May 20, 2020

bc3tech commented on May 20, 2020

jaydn commented on May 21, 2020

0x49D1 commented on May 21, 2020

sschuberth commented on May 21, 2020

sschuberth commented on May 21, 2020

crumdev commented on May 21, 2020

bc3tech commented on May 21, 2020

82 remaining items

Trance-Paradox commented on Mar 29, 2021

denelon commented on Mar 29, 2021

pratikpc commented on Apr 12, 2021

denelon commented on Apr 12, 2021

emass-sec commented on Apr 24, 2021

eidylon commented on Apr 25, 2021

Karl-WE commented on Apr 29, 2021

arcmodo commented on May 9, 2021

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

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

denelon commented on May 11, 2021

spragginsdesigns commented on Jun 13, 2021

denelon commented on Jun 14, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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

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