What about paid apps that have been purchased already?

If the entitlement is already granted, I think we can continue with installation.

Small typo:

Another aspect to consider: What would happen if the user updates an app that is not installed? Should it then display an error or install said app?

Should winget exit with a non-successful status code if this is the case?

Yes, I believe so. If the command requested cannot be executed, the process should return a failure exit code.

This seems counter intuitive to me, and it's also not what Linux package managers do as far as I know (using pacman here). If the purpose of the upgrade command is to check if newer version of package(s) are available and get them, then it didn't fail if the last available package(s) are installed already. The output should be different (f.e. "there is nothing to do") but the command would be considered a success anyway.

I guess it comes down to what the purpose is deemed to be semantically. I am not opposed to the purpose being "Make sure I have the latest version of this", which then I agree with you that no error is correct. I was reading it more as "Get a newer version of this", which while I agree is a subtle difference, it is still the difference between a command that cannot be executed, versus one that can.

I suppose there is the question of what is done in the --all case. In that case, should there be an error if no updates are available for anything? That feels wrong to me, as I don't think anyone would ever say "Get a newer version of everything". So for consistency, I believe that the semantics should be Ensure, not Get.

So I agree that there should not be an error exit code, and the verbage here should be "issue a warning" not an error.

A suggestion for what could be discussed here: The impact on users that have not used a package manager, will they naturally use update instead of upgrade (or sometimes have issues with distinguishing these two)? And on the other hand, if update was an alias for upgrade, how can similar functionality of upgrade be used with the alias and vice versa? (For example: #120 (comment)) It would be really nice to see what is the plan for dealing with this kind of complexity (update vs. upgrade) from a user standpoint.

I prefer "update'. Upgrade has other semantics (at least to me), and update fits more cleanly into what is happening.

@JohnMcPMS If you decide to go with update, then I would suggest to make upgrade alias of update to make the life easier for users familiar with other package managers that use upgrade for updating packages.

Brew user here, every time I want to update an app, I have to look up help to see if I need to update or upgrade. One is making sure Brew is up to date, the other is for updating the app. If you trigger update without supplying app identifier then Brew will attempt to update every installed packages. Which I'm not a fan of.

Personally, I'm against making alias between update and upgrade. Having just one version of them at the start should reduce confusion on which one to use for newcomers. Instead of doing this, I'd suggest WinGet to only offer just one.

• winget update - displaying help for update.
• winget update <package_id> - updating provided package.
• winget update winget - updating WinGet itself.
• winget update -a|--all - updating every installed packages.

I think winget should use keywork like apt of Debian.

• Update: for refresh the catalog
• Upgrade: for actual installation operation of new version

This way we could remove the refresh frequency as winget user does not expect winget run in background as a CLI tool usually run and exit

Would the user be prompted to confirm the package update? If yes, should there be flag to override this when being used in automation tasks, similar to how other package managers does this?

Sounds like a good idea to stick to that already established pattern where by default a confirmation is required to proceed that can be skipped by passing an additional parameter.

What about specifying a manifest file that is located on the user's machine (or another repository)? Would this be part of another spec?

It would be nice to hear how syncing with the remote repository will be handled, will the user have to do this manually (i.e. using an update), or will it be done automatically if the repository hasn't been synced after a said time?

Martin, I am curious. I think that the syncing of the remote repository is handled via the source:
C:\Users\kevinla>winget source update
Updating all sources...
Updating source: winget...
██████████████████████████████ 100%
Done.

Do you think this addresses the Update concern?

It is true you can handle this using the winget source command. I just think the spec should outline how the syncing of the remote repo is handled in context of running an update. Is a user required to run an winget source update before running winget upgrade or will this be implicit from running winget upgrade? (i.e. upgrade will invoke source update)

In Linux package managers update the package cache for all enabled repositories. If a package was installed from repository "foo" then the search for available updates for that specific application will be narrowed down to repository "foo". If you'd actually want to install a new package that is available in multiple repositories without explicitly providing the correct repository name, the package will be installed from the repository with the highest priority. This priority system is also how the upcoming version 3 of PowerShellGet has been designed to define repository ordering.

As of now, whenever a source (SQLite DB) is opened, it updates the source if it's been more than 5 minutes. winget source update is just the explicit command to update.

// TODO: Enable some amount of user control over this.
constexpr static auto s_DefaultAutoUpdateTime = 5min;

Handling available updates with this would be similar to how dotnet handles packages updates, nice 👍 https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-list-package

Not a huge deal, but I'd personally prefer the -h alias as it is far more common and more clearly maps to --help than -?

Isn't -? the standard on Windows while -h is more a Unix thing?