[Feature Request] Specify version to update app to
Joly0 opened this issue · comments
Hey, i havent tried this yet, but i havent seen any hints my feature request is already possible: for managing a larger group of devices in my opinion it would be useful to be able to specify the version an app should be updated to.
I think one could profit from such a feature, as this could give finer control over which version exactly is distributed and auto-updated on a range of devices.
This could especially help in companies with situations where a smaller team wants to test a new update of an application, without auto-updating it for everyone.
If there are any issues with a new release, not everyone would be affected but only a small test-group.
This issue is stale because it has been open for 30 days with no activity.
Still needed
Hello. It will not be easy to implement such feature. Winget is not very flexible. Managing different versions and the time they get applied is not really possible. Moreover, certain apps (like TeamViewer) share the same link for the latest version.
But if you have an idea how we can handle that... feel free
Hm, ok, i understand. But the feature i am trying to propose is already in winget. For example if i run winget upgrade, i get a list of my apps and for example this app
As you can see, the latest version is 3.2.3 for GithubDesktop but i could also run this command
and it installs the specified version right away
So in my opinion, it should be possible to specify the version an app should be aut-updated to aswell. I have looked into the code of this project and there should be the possibilty to add the version after the appid with a delimiter (i guess ; might work) in the registry for the key of the whitelist. So Get-IncludedApps.ps1 can split those informations and return AppIDs which now also contains the version that the app should update to.
"Winget-Upgrade.ps1" might be a little harder here around line 250. There might be the need for a second elseif here, that checks, if version $toUpdate contains app.version and if so, runs the Update-App function with the version parameter.
I might be able to look into this aswell on my own (i do know powershell quite good), but at the moment i dont have much time to look into this, so i thought this might be a good idea to suggest as a feature request
I understand the feature needs, but if I go with Teamviewer for example, we cannot use your suggestion as historical versions are not kept:
https://github.com/microsoft/winget-pkgs/tree/master/manifests/t/TeamViewer/TeamViewer
So, if another version is out in the meantime, you cannot manager deployment per "ring" for instance. It might cause issues.
I don't know if some other apps are like this, but I guess so.
Hm, i see the problem. Might it be possible to skip the update (maybe with a notification) for the issued app or update to the latest available version?
Additionally, is it possible to specify my own manifest for the auto-update process? That might help in those situations
you can work with your own manifest I guess, but you will have to manage a new source for winget and change the WAU scripts to handle the new source as by default everything is based on winget.
For instance https://github.com/Romanitho/Winget-AutoUpdate/blob/main/Winget-AutoUpdate/functions/Get-WingetOutdatedApps.ps1 :
#Get list of available upgrades on winget format
$upgradeResult = & $Winget upgrade --source winget | Out-String
You will need to change the source here
Might it be possible to have the source as a variable maybe as a reg key? I mean, officially here?
This is something we can manage I guess :)
In my environment for instance, I run WAU everyday on IT team, and once a week on the other machines.
I see. In my environment its a bit different. We publish apps for our IT testing Team once a month, let them test for a few days and if there are no issues, we publish the tested version to everyone else. But it already happened, that during testing and releasing for everyone, a new version of a software was available, which he had to skip until next month, due to the fact, that we have to test new releases first and we have a fixed schedule for the updates. This excludes important security updates, which we try to push out as fast as possible.
Thats why such a feature would be beneficial for us and i assume, there are other companies, that do it similarly to us.
I totally understand. But in that case this is not realty an auto update process as you have a validating phase.
We could think about adding the version in the white/black list but this will change the structure of the lists so we need to take care about side effects.
Yes, you are totally right, this wouldnt really be an auto-update, more like semi-auto-update or auto-update with validation, but i still think, this could be a useful feature and would be a nice addition to this otherwise useful project.
Regarding the testing i would be willing to helpp as good as i can.
from my point of view, in your context, don't use WAU. Just use https://github.com/Romanitho/Winget-Install (with SCCM, Intune or whatever) and manage versions inside this install command. This way, when you validate a new version, just change the version of the app inside the install command AND the detection method. Now winget handle install command as upgrade if an app is already installed.
something like this should work:
powershell.exe -Executionpolicy Bypass -Command .\winget-install.ps1 -AppIDs "Notepad++.Notepad++ -v 8.4.1"
Hey @Romanitho i have looked into it and you might be right, but the problem is, that the detection script only detects the presence of the app, not the version. So i would either have to use a custom detection method or the script would need an update to include the option to check version aswell.
But other than that, i think this might work. Thank you :)
Btw this project https://github.com/Romanitho/WingetIntunePackager is genius level
Thanks ;)
This issue is stale because it has been open for 30 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.