Upgrade an installed App about winget-cli HOT 94 CLOSED

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

from winget-cli.

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

from winget-cli.

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.

from winget-cli.

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?

from winget-cli.

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

from winget-cli.

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.

from winget-cli.

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.

from winget-cli.

I think the problem here is that there are two conflicting design approaches:

1. use terminology and ideas from popular cross-platform package/dependency management tools
2. stick with established Windows terms and ideas

In the past Microsoft/Windows have often been looked down on because they did things differently from current standards and some of those decisions have made Windows users suffer for ages. I believe that a combination of both is possible.

Approved PowerShell verbs can cover the use cases that we're dealing with here while making winget behave as close to the tools users know already, e.g.

from winget-cli.

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

from winget-cli.

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.

from winget-cli.

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.

from winget-cli.

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.

from winget-cli.

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

I am sure you are trying to be a dick, so good job. Download from release and there is an install exe? No there is not. But that like did lead me three more clicks to this page wich did have something I could install which seems to have worked. https://github.com/microsoft/winget-cli/releases/tag/v0.1.4331-preview
PS> winget
Windows Package Manager v0.1.41331 Preview
Copyright (c) Microsoft Corporation. All rights reserved.

WinGet command line utility enables installing applications from the command line.

Thanks for that. If you want some help writing directions that are meaningful and people can actually use, let me know. I am happy to create a zoom meeting and let you try and show me what you think I was missing, if you happen to be a genuine person that wants to make things better. I won't hold my breath. That downloaded APPXBUNDLE File. Microsoft.DektopAppInstaller_8wekyb3b8bbwe.appxbundle Nowhere is there an install executable as described.

from winget-cli.

actually this is a must have feature

100% agree that this is a must have. The main issue I have is never initially locating and installing an application, it's having to get notification that there is an update and then there is a link (Looking at your PowerShell 7.0.1, 7.0.2...) I have to go to, download, install, etc, etc. Otherwise, it's really only about 30% useful. The major long term benefit kicks in when I can update all of my applications time and time again with:

winget update && winget upgrade
(or similar)

Done.

This is precisely what I don't want.

from winget-cli.

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!!!!

from winget-cli.

Forcing naming conventions from the *nix ecosystem into Windows seems very counter-intuitive to me. Windows has always had a word for getting newer versions of your apps and itself and it has always been "update". I can't even name an app that requests an "upgrade" for a new version, although I'm sure there are some examples; "update" is almost always the word.

I also disagree that an update command without arguments should be interpreted as "update everything". Many CLIs use argless commands as a shortcut for getting help about said command. Scoop and conda solve this matter very nicely: scoop update * and conda update --all. Updating all packages should never be something invoked by accident.

from winget-cli.

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?

from winget-cli.

The "update" verb today is used in the context of sources: winget source update. It's not implemented as a "root" verb.

It looks like there is an overwhelming preference here to use the "upgrade" verb to update/upgrade/install the current version of a package.

winget upgrade <package> would install the latest version of the package (based on the current source meta-data)
winget upgrade would install the latest version of all packages (based on the current source meta-data)

In addition, the default behavior of the client would likely update the source meta-data before attempting the upgrade action.

The default behavior in the client is a five minute TTL to check the source and get the current list of available packages. With the configuration file, this can be adjusted or disabled. Note: Windows Package Manager v0.1.41771 Preview includes this functionality, and this or a newer version will be released soon.

from winget-cli.

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

from winget-cli.

The actual verbiage used is of no consequence to me, personally. The command could be named "makeithappen" and as long as it is able to update my software to the most current version, we're good to go. 👍

from winget-cli.

After reading through the comments, I am wondering, is there a way to see what apps need updating?
Unless I missed something in the thread, the way it is working right now

> winget upgrade

just upgrades everything, though it doesn't give you ANY feedback what it is actually doing.

Could we have something like
> winget upgrade list or
> winget search upgrades or
> winget upgrades

that would put out a list of all the apps that have available updates?

from winget-cli.

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???

from winget-cli.

Winget should support installing applications that are not yet installed with update(or upgrade) command.
When building an automated environment like CI, it is inconvenient to use different commands depending on whether the application is not yet installed or already installed.

from winget-cli.

I think winget's ecosystem is most similar to that of homebrew.

a) Both enable you to install applications and libraries from various independent software vendors (some of them built from source during install, some as a prepackaged binary or installer).

b) winget's manifests resemble homebrew's formulae and its update/upgrade terminology and principle is similar to that of (Debian's apt update / apt upgrade or RHEL's yum check-update / yum update).

The homebrew docs say:

First update the formulae and Homebrew itself:

brew update

You can now find out what is outdated with:

brew outdated

Upgrade everything with:

brew upgrade

Or upgrade a specific formula with:

brew upgrade <formula>

I personally like how brew handles the metadata update. It comes with a "self-update before run" pattern that is relatively common in other software and it will fix the almost daily issues we see where people haven't got a fixed version of software yet.

This HOMEBREW_AUTO_UPDATE setting is enabled by default. If a metadata update has not happened in the past HOMEBREW_AUTO_UPDATE_SECS (300s by default), the commands brew install and brew upgrade will reach out to the repository and update the metadata to the latest version. Repeated execution of these commands will then be served quickly from the local cache.

If I wanted to install a specific version I'd append @<version number> to the package name, e.g. to install golang 1.11 instead of the latest version (1.13) I'd specify brew install [email protected]. If I want to keep a currently installed version of a package, say wireshark, around and stop it from being updated when I do the natural update and upgrade procedure I can pin a formula:

brew pin Wireshark

Once you want to bring in the latest changes and updates, you can unpin it again:

brew unpin Wireshark

Pinning is definitely important for developers to avoid breaking changes in some toolsets.

Some more points I'd like to highlight:

• It also comes with some interesting configuration options that might inspire some features in winget as well.
• They also have various download strategies:

  def self.detect_from_url(url)
    case url
    when %r{^https?://github\.com/[^/]+/[^/]+\.git$}
      GitHubGitDownloadStrategy
    when %r{^https?://.+\.git$},
        %r{^git://}
      GitDownloadStrategy
    when %r{^https?://www\.apache\.org/dyn/closer\.cgi},
        %r{^https?://www\.apache\.org/dyn/closer\.lua}
      CurlApacheMirrorDownloadStrategy
    when %r{^https?://(.+?\.)?googlecode\.com/svn},
        %r{^https?://svn\.},
        %r{^svn://},
        %r{^https?://(.+?\.)?sourceforge\.net/svnroot/}
      SubversionDownloadStrategy
    when %r{^cvs://}
      CVSDownloadStrategy
    when %r{^hg://},
        %r{^https?://(.+?\.)?googlecode\.com/hg}
      MercurialDownloadStrategy
    when %r{^bzr://}
      BazaarDownloadStrategy
    when %r{^fossil://}
      FossilDownloadStrategy
    when %r{^svn\+http://},
        %r{^http://svn\.apache\.org/repos/}
      SubversionDownloadStrategy
    when %r{^https?://(.+?\.)?sourceforge\.net/hgweb/}
      MercurialDownloadStrategy
    else
      CurlDownloadStrategy
    end
  end

• Useful guides for users and maintainers: https://github.com/Homebrew/brew/tree/59c50986c78b53214b650d8ef84c797965396fc0/docs

from winget-cli.

Totally agree with that.

Windows Update -> winget update

As for updating all packages, winget update could list all apps to update and asks for confirmation Yes | No, maybe add additonal option like --yes | -y.

from winget-cli.

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.

As a Linux user i can state that just because you know how to use apt doesn't mean that the update vs upgrade nomenclature is not confusing. also, a lot of us use different package managers.

from winget-cli.

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.

from winget-cli.

Agree with this. A big plus for using Linux or macOS (especially under a development environment) is having access to a Package Manager, that gives you, the user, overall control over the versions of the packages installed. It's in the name Package 'Manager'.

This is especially important for packages/applications with a new version which can cause compatibility issues. Having global AND application specific 'update' (or any other method) functionality creates a simple way to manage this.

Otherwise, it kind of just feels like it's not a much of a step up from just installing via the Store or a third party .exe. Obviously Winget has some benefits over that, but in terms of 'managing' packages/applications, not so much.

from winget-cli.

The value in a separate update command is that it provides the user control. If I know a new version was added recently to one of my repos, I can run an update. I can also do it after adding a new repository manually via config file, and I can schedule it in task scheduler so my repo info is always up to date.

One change from Debian I do support is using uninstall rather than remove as I believe it is more precise and Windows users will know what it means. Perhaps remove could do the same thing to keep Debian users happy.

Once winget supports dependencies, configuration files, and such it should also support purge and autoremove commands.

I agree that it should be possible to install/pin specific package versions and the homebrew syntax makes sense. So everywhere I put <package> you can substitute <package@version>. Examples, winget install [email protected] and winget pin [email protected].

I suggest something like the following:

• winget update to update metadata from all repositories. No arguments accepted.
• winget upgrade to update metadata if it hasn't been updated in the past 10 minutes and then upgrade all installed packages.
• winget upgrade --no-update to upgrade all packages based on local (not updated) metadata.
• winget install <package> or winget upgrade <package> to update metadata if it hasn't been updated in the past 10 minutes and then install or upgrade only <package>.
• winget install --no-update <package> or winget upgrade --no-update <package> to install or upgrade only <package> based on local (not updated) metadata.
• winget uninstall <package> to uninstall an installed package.
• winget pin <package> or winget unpin <package> to pin/unpin the current version of an installed package so it will not be automatically upgraded.

from winget-cli.

As there is already a lot of confusion with the support of automatic updates/upgrades in chocolatey (it does not recognize new versions of self updating packages) I would strongly suggest to put the information about self-updating in the package information, e.g.
a software should have the possibility to say that it updates itself after it was installed once and there should be information on where to automatically get the currently installed version to check for updates and with that information the package manager should have a feature to get the current version at a future point in time.

From a users perspective it is irrelevant if the package is going to be updated and not the software itself. So its okay if a package is changed and an update then does not change the software installed, yet if there is a new version of the software available, an update via the package management should also install that new version and get rid of the old version if it is not replaced.

To make it clear: A user would expect the software is updated in almost all cases, manual pinning should not be required (but yet could be used in addition)!

from winget-cli.

actually this is a must have feature

from winget-cli.

I think winget should have direct connection to local add/remove software so it can see installed applications, and if any are available under winget repo it will add it to the list of tracked applications and this should be tracked after every update all command. so updating doesn't cause version issues when using multiple version of certain apps.

from winget-cli.

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.

from winget-cli.

@dev-nicolaos Those were simply arguments from an UX perspective, I don't say that should be the main reason why they should avoid having an upgrade/update command, I am only bringing it up into the discussion.
If the reality is as you say that many Windows users are scared of the command line, we should make it a more friendly environment for those who are new, so that they are met with tools that are easy and convenient to use, and not some tools where they have to learn and understand that there is some repository that they need to sync first in order to install a new GPU driver. That is technical complexity that drives those users away from CLIs in the first place, it also makes my life harder as a sysadmin when I administrate servers as I have to type two commands for doing one thing.
I fail to see your argument as I would say it is entirely unnecessary having to read documentation in order to know which set of commands you have to run in order to update software from a package manager. If anyone has need for skipping the repo syncing, then there should be a need for looking up in the docs as that is not something people will use for the most part.
Note that I am not arguing that we shouldn't support this use-case, only that we should optimize the tool for what 90%+ of what the users will use it for in terms of UX.

from winget-cli.

Great feedback. I have an early draft started of the spec based on the above and some of my ealier thinking. For example the comment "I believe it's also important to be able to list all available updates without actually installing them", my proposal is a list command.
#397

from winget-cli.

Don't they all use upgrade?

Not all do. The two package managers I use most frequently, Scoop (for windows) and npm (for Node) use update (though npm does alias upgrade).

Personally I'm down for whatever name (heck, just call it up, less characters) as long as the functionality is right.

There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

from winget-cli.

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

from winget-cli.

I agree that we should leave out the complexity of update/upgrade since that could in some cases lead to user-error. Inexperienced users may not understand or know they have to run update before upgrade (imagine the amount of people ranting about how they have to update before running upgrade when all they are going to do is update packages), and in some cases users might even forget to run update.

I'd be cautious about making such a big design choice based on the fact that some users are unfamiliar with that paradigm. Remember who the target audience is. Most Windows users likely won't use winget because...

1. Windows has established patterns of installing software via the Store and web
2. many Windows users are uncomfortable working in a command line/terminal environment.

This means the most users who will use winget are likely either already familiar with command line environments or are comfortable learning a new technology. Gaps in user knowledge can also be filled in part by producing good learning materials such as tutorials and documentation and making them easily available.

TLDR: While making software intuitive is a good goal, I don't think a potentially important feature should be dismissed because "imagine the amount of people ranting" that the program doesn't work exactly how they expect. I like the idea of separate commands, but with a flag on the update command that also performs an upgrade.

from winget-cli.

There will be GUI wrappers around winget if it takes off. These probably already exist.

There's no reason to reinvent the wheel, keep the existing behavior familiar to debian users where update=update repo info and upgrade=upgrade package. There are reasons to force a repo update, there is value in separating these commands. And yes it does make sense for upgrade to also update repos if they're stale.

from winget-cli.

@rodalpho What value does it bring, and what problem are we solving by having these as two separate commands? I disagree that this is a "reinvent the wheel" approach, and we would pretty much stop up with any progress in software engineering if we took that argument into account when creating new software. The package manager should be similar to other package managers, but we should not constrain the design of it to the mindset of what was valid 10-20+ years ago.

from winget-cli.

@martinmine

Those were simply arguments from an UX perspective, I don't say that should be the main reason why they should avoid having an upgrade/update command, I am only bringing it up into the discussion.

From another UX perspective, some users prefer having separate commands so that they can see what has updates available and whether they will be major versions before upgrading. I think both are valid use cases.

If the reality is as you say that many Windows users are scared of the command line, we should make it a more friendly environment for those who are new, so that they are met with tools that are easy and convenient to use, and not some tools where they have to learn and understand that there is some repository that they need to sync first in order to install a new GPU driver.

I'm saying the reality is that many Windows users will never use winget or any other CLI, no matter how easy to use it is. How many people on MacOS don't use Homebrew? The average user who isn't a sysadmin, dev, or tech junkie is unlikely to be interested in learning the command line.

it also makes my life harder as a sysadmin when I administrate servers as I have to type two commands for doing one thing.

That's a fair use case, and as I said I like the idea of having a flag on the update command to upgrade if available as well. Or as @rodalpho proposed...

And yes it does make sense for upgrade to also update repos if they're stale.

I fail to see your argument as I would say it is entirely unnecessary having to read documentation in order to know which set of commands you have to run in order to update software from a package manager.

One of the great things about a CLI is that's it's really easy to embed documentation directly in the experience. The first thing I usually do when running a new CLI is run newCLI --help. Since a user can't just click around a GUI to find out how to use the software, there will almost always be a need for some (light) reading in order to understand how to use a powerful CLI.

from winget-cli.

@dev-nicolaos the --help argument would be documentation :) I don't think we should make tools harder to use simply because "they should be interested in learning it". I would argue that so many Windows CLIs are awfully inconvenient to use, especially compared to Linux-based CLIs and this is why so many Windows devs avoid CLIs. Let's not make that mistake again.
What @sschuberth proposed is imo the most ideal that suites all view-points so far in the discussion:

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.

from winget-cli.

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

I think aliasing would cause confusion for those familiar with other tools that use update and upgrade for different purposes. A better solution would be to display a message when somebody uses the update command to say that is isn't needed (if that is going to be the case) or not yet implemented.

from winget-cli.

I alias everything to just _up or _upg no matter what they are, so its always the same anyways.

from winget-cli.

winget upgrade -all

I have a feeling that a lot of people are gonna write winget upgrade --all, what's the reasoning for having one dash instead of two?

from winget-cli.

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.

from winget-cli.

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.

from winget-cli.

winget plans to support package dependencies (#163).
This feature requires many considerations in the design of tool and repository.

For example, if an application X depends on version 1.0 of another application Y, and there is no compatibility between versions 1.0 and 2.0 of Y, then Y should not automatically update to version 2.0 as long as X is installed.
The user should not have to run a command like 'winget pin' to avoid such automatic updates.

To support package dependencies, support for side-by-side installation of the application is required. Multiple versions of application Y may be installed at the same time (though many applications do not support this).
The command 'winget update Y' allows updating which installation to which version?

Application versioning is not all compliant with Semantic Versioning. Updating from version 1.0 to 1.01 can also break compatibility.
winget cannot automatically determine whether an update is acceptable or not based solely on the version number.

If Y is installed as a dependency of X, then maybe that version should be pinned automatically. It will not automatically update when a compatible Y 1.1 is released unless a new manifest for X states dependency on Y 1.1.

Another idea is to be able to declare a compatible version range in the manifest. For example, the metadata for a plugin in Jenkins has this entry.
When version 1.1 of Y is released, it will automatically update to 1.1 if its manifest lists 1.0 as a compatible version.

If you're using the application Z installed as a standalone and a new incompatible version is published, it would be helpful if winget would alert you to that when you update or guide you to an upgrade guide if it's provided.

If a new version of an application is released but does not update automatically, you need to consider the importance of that update. For example, there may be a critical security vulnerability in an older version.
In such a case, maybe the warning should be displayed, even if it doesn't update automatically.

from winget-cli.

I think it's quite non-important how the command will be named.
Important for me is that there is a possible way to update/upgrade installed applications using winget - including winget itself.

from winget-cli.

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.

from winget-cli.

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

from winget-cli.

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

from winget-cli.

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.

from winget-cli.

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

from winget-cli.

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.

from winget-cli.

* **winget update** to update metadata from all repositories. No arguments accepted

It'd be nice if this command (if it's implemented) highlighted updates to installed packages so that the user can easily see if any of the updates were relevant to them. An alternative is a separate status command like scoop implements.

from winget-cli.

I am still not convinced 😄 upgrade --no-update sounds contradictory, but if the user would use this parameter they would know about the concepts of what "update" implies. @rodalpho what is your argument that your proposal provides more user control over the interface that @sschuberth proposed earlier, and why does it outweigh the usability aspect of it?

from winget-cli.

Sorry, that I did not read the whole issue, before dropping this comment here (it may be dublicate):

The user facing normal update package operation should be doing both:

1. pull the repository
2. update the package, if there is a new version.

This will avoid millions a future issues (i gues homebrew have learned that lesson).

Looking forward to this feature, and many thanks

from winget-cli.

Until we have the ability to pin packages, we were leary about winget upgrade upgrading all packages. That's why we went with winget upgrade --all. The command currently accepts a package Identifier to update an individual package. This feature is still experimental, so it may change before it is released as a stable feature.

from winget-cli.

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.

from winget-cli.

i support it.

from winget-cli.

This will be a great feature

from winget-cli.

I agree that we should leave out the complexity of update/upgrade since that could in some cases lead to user-error. Inexperienced users may not understand or know they have to run update before upgrade (imagine the amount of people ranting about how they have to update before running upgrade when all they are going to do is update packages), and in some cases users might even forget to run update. While it does save bandwidth and has a use-case with offline usage, edge-cases like this should not make the tool harder/more inconvenient to use. A great tool is easy to use right, and hard to use incorrectly, and I would argue the complexity of the repositories should be left out of regular use-cases. The syntax that @sschuberth proposed is a great start for how this can be done without affecting what most people will use the tool for.

from winget-cli.

I explained my reasoning further in the same post you're responding to.

@dev-nicolaos: My suggestion would be to just winget upgrade, where it lists all available upgrades then asks for confirmation to install them. I don't know that a winget show-upgrades or similar is really necessary.

from winget-cli.

The actual verbiage used is of no consequence to me, personally. The command could be named "makeithappen" and as long as it is able to update my software to the most current version, we're good to go. 👍

I'm guessing you don't use any other package managers then.

from winget-cli.

Why is that? I use apt, brew, scoop, and choco.

from winget-cli.

Don't they all use upgrade? I personally like consistency. Anything to reduce the mental load has to be a good thing.

from winget-cli.

NPM uses npm update to update all packages.
I personally never had problems with that but a JavaScript project is something else than an OS.

from winget-cli.

I agree with Seb @megamorf as above.
Since there are already good requests for having winget powershell like commands
#221 and compatibility.

I would like to add that I have also seen the PowerShell update notifaction as mentioned @MostHated
I have not installed PowerShell with winget on this system, yet was able to update it via Winget install PowerShell.

Personally I would also prefer winget update over upgrade.
The reason fits with @megamorf

from winget-cli.

I think winget should have direct connection to local add/remove software so it can see installed applications, and if any are available under winget repo it will add it to the list of tracked applications and this should be tracked after every update all command. so updating doesn't cause version issues when using multiple version of certain apps.

This should be fairly easy to do for programs installed as MSI because they have a unique GUID so winget can easily match them against its repositories - but for EXE installers, this is going to be impossible (aka if you try, it's always going to be buggy and hell to maintain)

from winget-cli.

Kind of hard to alpha test this if we can't use it. Because we can't actually upgrade or uninstall Our packages.

from winget-cli.

All, the experimental version of upgrade depends on the experimental list command, but you should be able to test it. You will need to enable those two experimental Features in your settings.

from winget-cli.

winget upgrade will shows which packages have upgrades available.
winget upgrade --all performs the upgrade on all packages that have upgrades available.
caveats: msstore packages are always versioned as "latest", and not all package versions match the installer version.
winget upgrade -? provides help for the upgrade command.

edited: from "-all" to "--all"

from winget-cli.

-: is for abbreviated commands

and

-- is for their long form or the only long form (there usually can only be 26 short forms)

but other characteristics are there to this as well: https://serverfault.com/questions/387935/whats-the-difference-betwen-the-single-dash-and-double-dash-flags-on-shell-comm

from winget-cli.

In that case, why not winget upgrade -a?

from winget-cli.

I fixed the typo.

from winget-cli.

One thing I find off is that I normally would expect that I would upgrade everything when I run winget upgrade and a prompt would ask me if I would upgrade all the listed packages. If I would only list them, I would run winget upgrade --list. I would assume that upgrading most packages is a far more common scenario than just listing all the packages.

from winget-cli.

If I would only list them, I would run winget upgrade --list

I think to list anything, there should be winget list command, possibly, winget list --upgradable as the apt does it or winget list --outdated as pip does it.

winget upgrade to upgrade everything.

winget upgrade <list of packages> to upgrade selection, or pip way winget install --upgrade <list of packages>

One way or another (e.g. pip, apt or similar interface), winget upgrade should mean action to bring packages up to date, not list them, similarly to winget install which means to install a package.

from winget-cli.

So what it is capable to upgrade now? I tried winget upgrade PowerToys but it shows 'No applicable update found.' In fact, if I do winget upgrade the output is:

Name      Id                  Version Available Source
------------------------------------------------------
PowerToys Microsoft.PowerToys 0.31.1  0.31.2    winget

from winget-cli.

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

from winget-cli.

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

from winget-cli.

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

from winget-cli.

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.

from winget-cli.

Winget upgrade is not working for me

from winget-cli.

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

from winget-cli.

@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

from winget-cli.

@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

from winget-cli.

@denelon why not just winget upgrade *?

Instead of --all?

from winget-cli.

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

from winget-cli.

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.

from winget-cli.

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.

from winget-cli.

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

from winget-cli.

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.

from winget-cli.

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

from winget-cli.