Installed version "unknown": Remove from winget-pkgs?

[Master-Guy]

There is a number of applications that can be installed by winget install that report version "Unknown" after installation. When looking at Programs & Features, these apps have no version at all. Three examples of these apps are:

• Blizzard.BattleNet
• CrystalRich.LockHunter
• Nadeo.TrackManiaNationsForever

When running winget upgrade --all, these packages are always re-installed, which can cause a huge download and installation time (TrackMania), even though it's not updating anything and just installing the same version again. Even worse, it will kill running applications for no reason at all, that the user might be running at that moment, or the applications cause pop-ups (LockHunter) or show their splashscreen (Battle.Net) after installation.

To improve usability of winget upgrade and to nudge publishers into correctly putting in version information in to their packages, my suggestion would be to remove these packages from /microsoft/winget-pkgs/. This does prevent users from installing the applications with winget install, but will prevent a lot of wrong stuff happening later and improve the global package information health.

[OfficialEsco]

winget upgrade just came out of experimental which is why there is a lot of issues with it.
The better solution would be to ignore unknown and latest.
Or you know, you could just not do winget upgrade --all all the time until its fixed.

[emarsk]

Winget could copy brew and have winget upgrade (with or without --all) ignore unknown/latest versions, and winget upgrade --greedy behave as now.

[denelon]

@Master-Guy we're trying to meet publishers where they are. I hope the Windows Package Manager will help shed some light on challenges with versioning and packaging. As a community, we will all need to work together to improve the experiences for installing and upgrading software. Many edge cases with different install technologies have existed for decades, and they are just now being exposed in a more "mainstream" way with the 1.0 release of the Windows Package Manager. I would suggest gentle and constructive feedback. I don't think publishers, or ISVs are looking to create bad experiences.

In several cases, it may just be a matter of finding the right installer URL, or letting the publisher know about the experiences you're having so they can be made aware and look into the opportunities to improve our experiences.

[KaranKad]

I think winget should remember app version instead of completely relying on control panel/settings app, this feature could also help in future when winget supports portable apps as they don't register themselves in control panel/settings app, winget will be the one to remember their version. Now this would not work much well when a person already has installed a app and then started using winget, but once winget is used to update the app, winget could somehow link to the app and remember the proper version after that. This does not mean we should completely throw away idea of using info from control panel/settings app tho.

[denelon]

@KaranKad we have that on the backlog. We're going to record what was installed. The challenge is a user might have upgraded outside of the package manager, so we still might not know what version a user has on their system. This is an area where publishers could help by properly reporting their version. Ideally with a semantic version.

[iDolmatov]

As previously mentioned in another discussion, why not use a more precise file versioning than unordered registry entries?
In the manifest file (it can be with a separate name in the parent folder of the program), specify the path to the file with the version number. Often developers use the correct notation for the version number in the executable file and DLL, because this is due to the nature of programming.
The file can be named Upgrade. Inside there will be the main parameter Enable (false, true) and the path to the file when the update is enabled.
This implementation can avoid updating programs that cannot be updated without consequences (resetting program settings, incompatible license, incompatible configuration with associated components of other programs, etc.)
If the update of a certain program is prohibited globally, a notification about this is displayed to the user. Additionally, you can implement a forced update parameter, i.e. the user understands the consequences and starts such an update mode himself.
In addition, you should make a list of exclusions for programs that cannot be updated in the user settings. This list is updated at the discretion of the user (the reasons listed or the desire to use the old version).

For starters, I recommend that you implement only the manifest and update configuration. Then it will be possible to quickly solve the compatibility problems of software updates. Moreover, both from the side of the repository for all users, and from the side of a specific user.

[denelon]

@iDolmatov we're working with a set of assumptions and best practices. It would be lovely if everybody built perfect software and used semantic versioning. I'm sure my younger self is guilty of both of these common maladies, and I will continue making mistakes as long as I'm alive.

For the Windows Package Manager, the current best practices involved in attempting to determine if a package on a Windows 10 machine needs an upgrade, and one is available in a source, is looking at the metadata from Add/Remove Programs (and/or registry entries). We can't assume users won't download or install software from other sources, or that software won't update itself. The other half of the problem is the manifest itself. We do have issues on the backlog to look at adding an array of metadata per installer node.

Package "pinning" is on the backlog as well so a user can inform the tool they do not want upgrades beyond a certain version.

Keeping a record of what the package manager installed is also more work "TO DO".

All of these things will take time to build and test. We will sequence them based on community input, and we will attempt to maximize the benefit for the largest number of users with each step.

Many users aren't software engineers. They just want programs installed on their machines. Plenty of manifests will be added by people who aren't familiar with all of the caveats, constraints, or implications involved in submitting a manifest. I think that's awesome! We have a unique opportunity to make it easier to install software on Windows. To some extent, we will have to absorb some complexity in the manifests in order to make things simpler for our customers. That means longer design cycles and longer testing cycles. I don't think there is one right solution. I think there are many of them, and we're attempting to be consistent with the trade-offs we make.

I think you have made some great suggestions, and I'm looking forward to future input. Be sure to dig through the backlog to add your 👍 to any Issues you feel should be high priority.

[kneelesh48]

Apps installed without winget like those installed with an exe file also show up in winget list so the only way to get their version would be to look at the Control Panel list. I don't think keeping a DB of app version when it is installed via winget is a good idea at all. Most Electron apps I use like Spotify, Discord, VS Code are self updating and those apps will show outdated version in winget if we keep a DB of the version when it was installed with winget.

[lychichem]

@denelon Can we add a function, that is, when using winget list and some package(s) are detected having no version numbers but are added to winget source, winget will automatically add a displayversion registry key using the packageversion string in manifest files? Like what I mentioned in #18089 (comment) ?