Apps installed should optionally auto-update

[TravisSpomer]

Description of the new feature/enhancement

If I install something with winget, it should update automatically in the background without me ever having to explicitly tell it to, like most existing package managers and launchers on Windows: the Windows Store, Steam, Adobe Creative Cloud, and so on.

Proposed technical implementation details

• Some people won't want this, so it should be possible to disable the behavior via a setting.
• It's plausible that someone might want to update everything automatically except for a single package, perhaps one that introduced a severe breaking change. The package registry could split it into badapp and badapp-legacyfork but it would be far preferable to be able to say "update everything automatically except badapp". (Conversely, some users who might want to turn off auto-updates entirely might still want one or two packages to indeed update automatically.)
  • In addition to that user setting, some individual packages might want to block automatic updates regardless of user preferences.
• winget should probably only automatically update apps to versions that have been released (and not recalled) for a week or some other holding period, to avoid a situation where a bad update immediately breaks thousands of people across the world.
• When running the update command manually, in addition to updating packages normally, winget should tell me of the changes it made automatically since the last update.

[RichiCoder1]

I'm not sure about auto-updating, but update-all with support pin-ing packages and the ability for maintainers to mark their packages as having their own auto-updates would be great.

[TravisSpomer]

From my perspective, initially getting and installing tools is something I do once a year or so, but updating is something I need to do constantly, so that's where there's the most room for improvement from something like winget. Requiring me to manually start up a terminal and run a command every week or so seems very last-century, when it's something that could have easily been done for me when I wasn't around. Without automatic updates, using a package manager just doesn't seem useful enough to bother.

Initially I was thinking that it would be a good compromise to just notify me in some fashion when an update is available, but I imagine most people would end up using one tool that updated constantly, which would just turn the notifications into annoying noise.

[NicTanghe]

From my perspective, initially getting and installing tools is something I do once a year or so, but updating is something I need to do constantly, so that's where there's the most room for improvement from something like winget. Requiring me to manually start up a terminal and run a command every week or so seems very last-century, when it's something that could have easily been done for me when I wasn't around. Without automatic updates, using a package manager just doesn't seem useful enough to bother.

I c what you mean but if auto updating is the way that is chosen packages auto update should be togglable.
And conflicts with dependancies should always be mentioned and then not update packages that depend on the same thing that cant auto update becouse it is a dependancy for another package.

Also managing range of version dependencies aka compatible with version 1.0 - 1.79 seems like mess to maintain / enforing people to update their package when their dependancy has an update seems like a monumental task.

[fantesykikachu]

Honestly with something like this, I think it makes more sense to do it like the linux package managers; allow winget to update all programs with a single command, and then use task scheduler to check for and update every day. Otherwise there would need to be a service which wouldn't be very clean.

Also if you want the ability to only automatically update certain programs, then it is almost easier now by just creating a batch file that updates each program and having a task run that each day.

[Elias-Graf]

I like the approach of the Linux package manager snap (more update references). As they state

updates are an integral part of the software lifecycle.

But I don't completely agree with snap's philosophy. I think, like snap, auto-update should be enabled by default, but:

• Allow users to pin versions. It's not uncommon that a certain version of any given app breaks something or doesn't work for a variety of reasons. Apps with pinned versions should not be updated until the user specifically changes the update target back to "latest" or something similar (maybe some sort of channel feature where one could also specify certain versions. As an added bonus, this could stop apps from having multiple packages for example for a beta version (i.e. signal has OpenWhisperSystems.Signal and OpenWhisperSystems.Signal.Beta). I think there should be some sort of prompt though, that reminds the user (like all 7 days) that they still have pinned apps. It's very easy to forget that sort of thing.
• Allow users to just simply turn off auto-update, either completely or for specific apps (the latter could be implemented using the pinning with some sort of syntax sugar).

[denelon]

@Elias-Graf I just put Pin a Package #476 in the 1.2 milestone. I hope we're able to get it in that release. Be sure to 👍 that one.

[Romanitho]

I've started to try something to auto-update, as it was something we needed with Intune
https://github.com/Romanitho/Winget-autoupdate

[iMonZ]

I'm not sure about auto-updating, but update-all with support pin-ing packages and the ability for maintainers to mark their packages as having their own auto-updates would be great.

That's why I don't like Homebrew anymore because they added this function.
I disable every autoupdate because autoupdate are not making any sense.
Why should every app on your Computer check for an autoupdate instead of one service like iOS and Android or the Store versions are doing.

Oh, and btw. winget checks for a Package version so if the app itself makes an autoupdate, winget will no longer detect it as outdated.
So this flag is not needed at all

[iMonZ]

I've started to try something to auto-update, as it was something we needed with Intune https://github.com/Romanitho/Winget-autoupdate

This is gold wroth.
Intune + Winget would make Windows great again.
I hope its get officially supported ASAP with auto update function

Is it possible to install your tool over winget?

We have 30 IT people that need that!
Thank you so much

[sitiom]

For my use case, I would like to have a tray application to manage updates, just like any other mature package managers. I want to have a tray application that can automatically update or notify me for updates at a set interval to update it for myself.

Update: WingetUI now provides this feature! See comment below.

Here are some references:

https://github.com/zkokaja/Brewlet

For example, you need to manually check if some of your packages can be updated. With Brewlet it's easy: if everything is working swimmingly, then you'll see the normal shadow icon. If updates are available to be installed, the icon will become colored, , to get your attention – along with a notification if you wish. Once clicked, you'll be able to upgrade your packages, among other options. In addition, Brewlet will periodically check the status of packages in the background, so you don't have to.

https://github.com/cokelid/ChocoButler

[iMonZ]

For my use case, I would like to have a tray application to manage updates, just like any other mature package managers. I want to have a tray application that can automatically update or notify me for updates at a set interval to update it for myself.

Here are some references:

https://github.com/zkokaja/Brewlet

https://github.com/cokelid/ChocoButler

Great idea but please no optout of autoupdates.

[MadSpindel]

Something similar like podman-auto-update could be an effective way forward?

podman auto-update looks up containers with a specified io.containers.autoupdate label (i.e., the auto-update policy).

If the label is present and set to registry, Podman reaches out to the corresponding registry to check if the image has been updated. The label image is an alternative to registry maintained for backwards compatibility. An image is considered updated if the digest in the local storage is different than the one of the remote image. If an image must be updated, Podman pulls it down and restarts the systemd unit executing the container.

The registry policy requires a fully-qualified image reference (e.g., quay.io/podman/stable:latest) to be used to create the container. This enforcement is necessary to know which image to actually check and pull.

https://docs.podman.io/en/latest/markdown/podman-auto-update.1.html

[sitiom]

For my use case, I would like to have a tray application to manage updates, just like any other mature package managers. I want to have a tray application that can automatically update or notify me for updates at a set interval to update it for myself.

Forgot to update it here, but WingetUI now solves exactly this feature (it also has a GUI and even supports Chocolatey and Scoop!)

[denelon]

Hey everyone, now that Dev Home is out, we might be able to consider this feature as a part of that experience. This capability a better fit for a service that is "always on". I don't know that we would necessarily want this only to run when Dev Home is active, but adding UI to WinGet doesn't seem to be the best fit. It seems to me that it might make more sense to add some kind of service to Dev Home where we would have UI controls to enable/disable and configure the behavior.

I also have some concerns about the extra load associated with downloading the PreIndexed package cache for the community source essentially constantly and the additional load on REST sources.

[RobCannon]

I think it would be pretty neat if some combination of DevHome/winget configuration could be used to not only specify a package to install, but to specify a range of versions. There would need to be some mechanism to apply the configuration on a scheduled basis (once a day, once a week, etc..) to re-apply the configuration and potentially update any packages that have a new version available.

Right now, DevHome applies the configuration once, so one big change would be to register a configuration (really, 1-n configurations) with DevHome so it remembers which configurations to re-apply. This would be great because it would allow a team to create a specification that keeps all team members at the same version of a particular package.