winget-cli: Window Terminal version "1.12.10983.0" will appear in winget upgrade but can`t be installed (Win10)

We need to add support for filtering out updates by the OS on the client. That will resolve this issue.

Now if we can only convince @denelon to let me spend a few weeks creating a whole new index schema, CDN cache structure, and associated code…

The improved searching is still questionable in my mind; I would want to know that Foo exists, is in the repository of packages, but is not available for my current system. Pretending like it is not in the repository of packages will just lead to confusion in my mind.

I could see it both ways. As a user, if there is a version which is compatible with my setup, I would want to see only the versions which are applicable to the setup. If there are no versions conpatible with my setup, I would want to know that the package does exist but isn’t compatible.

The newest release of windows terminal includes a windows 10 and windows 11 version. It seems that winget has the windows 11 version.

https://github.com/microsoft/terminal/releases/tag/v1.12.10982.0

@Trenly didn’t you create a issue? 😬 Would you mind explaining your findings?

No, this was the issue I was referencing, and after digging into the code more it seems that I was partially mistaken.

There is a section of the code called the ManifestComparator which, from my understanding, is used when the CLI is selecting which installer to use from a manifest. The manifest comparator has various fields called “FilterFields” that narrow down which specific installers may be used. Specifically, there are filter fields for architecture, installer type, and in this case, there is also one for MinOSVersion.

I originally thought the filter was broken, but I now belive I just misunderstood how it gets applied. As shown by the No applicable update found. the filter actually is working. Since it cannot find a version compatible with win10, it deems there to be no applicable installer. In the install flow, this terminates the command. In the update flow, it falls back to the latest version with an applicable installer. If the installed version is the latest applicable or greater, then it terminates with no applicable installer.

@JohnMcPMS seems to have a great understanding of what the issue I described above is, stating it in your initial pr. Although, I don’t know that all the details were fully explained. If a user is on v1.12.10732.0 they will see 1.12.10983.0 when they run an upgrade. But, the upgrade will actually install 1.12.10982.0 since it is the latest version with an applicable installer. If the user is already on 1.12.10982.0, then they will get no applicable update found. The installation flow does not have this fallback method as mentioned in the initial pr.

Overall, it seems that the MinOsVersion is not considered at all when fetching results from the source, and is only considered when an upgrade or install is invoked. Based on this issue, I would suggest that this is the true bug, not that install doesn’t have a fallback. If a users system does not support a version, then it shouldn’t be listed as available in either search, install, or upgrade in my opinion.

I know that @ryfu-msft implemented some logic to check that a system supports a portable app before installation. Perhaps the type of issue seen here is a more systemic one, since it brings to my mind the question - should portable apps even show up in Search/Install/Upgrade if a users system does not support them? However, that question is a topic for a different thread. I’m just asking it here to spark thought and consideration.

Work in progress:

• microsoft/winget-pkgs/issues/111840
• microsoft/microsoft-ui-xaml/issues/8632

We’re planning on having dependency support in WinGet 1.6. Testing can be performed by enabling the experimental feature for dependencies in WinGet and using a local manifest.

One of the dotnet sdks will download repeatedly every time an upgrade --all is run.

so this seems to be a different problem.

It is indeed a very old issue which has nothing to do with this issue.

• https://github.com/microsoft/winget-cli/issues/1142
• https://github.com/microsoft/winget-cli/issues/2011
• https://github.com/microsoft/winget-pkgs/issues/17985
• https://github.com/microsoft/winget-pkgs/issues/38045

@Trenly I don’t think splitting the manifests would be a good idea in this case. There would be multiple matches and it might end up being challenging similar to what we’re currently facing with VC++.

Makes Sense; I thought that if there were some way to differentiate them using ARP data, it might filter it down to a single match

I agree conceptually that it would be best to filter out versions when they are not applicable and support the state of no applicable versions. We could output N/A or similar as the version to indicate in search “we have this thing, but not for you”.

However, I think that with the current design this is complicated technologically. I wouldn’t want to do this for just the OS version; it would be for all applicability concerns. So we would need to do applicability filtering for every version of every result in order to get the right answer for “latest” (and even then, should winget show foo --versions list inapplicable version with an *?) This is a lot of data to add to our current design. I do have thoughts on an evolution though that this would fit in to.

Now if we can only convince @denelon to let me spend a few weeks creating a whole new index schema, CDN cache structure, and associated code…

For upgrade yes, we would need to filter each version by applicability factors. OS version is only one of those.

I think we need this for search and show as well. This is what I see on Win10:

PS C:\> winget search Microsoft.WindowsTerminal
Name                     Id                                Version      Source
-------------------------------------------------------------------------------
Windows Terminal         Microsoft.WindowsTerminal         1.12.10983.0 winget
Windows Terminal Preview Microsoft.WindowsTerminal.Preview 1.13.10734.0 winget

PS C:\> winget show Microsoft.WindowsTerminal
Found Windows Terminal [Microsoft.WindowsTerminal]
Version: 1.12.10983.0
[...]

PS C:\> winget show Microsoft.WindowsTerminal --versions
Found Windows Terminal [Microsoft.WindowsTerminal]
Version
------------
1.12.10983.0 # not applicable
1.12.10982.0
1.12.10733.0 # not applicable
1.12.10732.0
1.12.10393.0
[...]

So both show me info for a release that is not applicable to my OS version. This is confusing for the user, IMO. E.g. I might be wondering, why I the version shown here does not install (assuming that the install gets the fallback), or show might give me information about a bug fix in the ReleaseNotes that is yet fixed in “my” version.

The fallback on install is the right thing to do here and in general. The improved searching is still questionable in my mind; I would want to know that Foo exists, is in the repository of packages, but is not available for my current system. Pretending like it is not in the repository of packages will just lead to confusion in my mind.

I agree w.r.t install. The following is information is useful (assuming that fallback would work and there would indeed not be an applicable installer).

PS C:\> winget install Microsoft.WindowsTerminal
No applicable installer found; see logs for more details.

PS C:\> winget install Microsoft.Terminal
No package found matching input criteria.

I disagree w.r.t. upgrade, search and show. Why would a regular user want to see information about a package that she cannot install anyway? There might be a use-case for an advanced “Is this package in the repo (even if it is not applicable for my system)?” option, but not as a default behaviour, IMHO. (It’s possible that you meant that with your edit, @JohnMcPMS, I just wanted to clarify.)

The newest release of windows terminal includes a windows 10 and windows 11 version. It seems that winget has the windows 11 version.

https://github.com/microsoft/terminal/releases/tag/v1.12.10982.0

Winget has both versions. winget show Microsoft.WindowsTerminal -s winget --versions