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

[ali50m]

Brief description of your issue

Window Terminal version "1.12.10983.0" will appear in winget upgrade but can not be installed on Windows 10.

Steps to reproduce

precondition: winget installed.

installed the latest version (1.12.10982.0) for win10.
run "winget upgrade" in WindowsTerminal, you will see the avaiable "1.12.10983.0" for Microsoft.WindowsTerminal. But you cant upgrade to this version, seems its the only for Win11.

Expected behavior

Please dont display this upgrade on Win10 terminal, if it cant be installed. I always keep my "winget upgrade" clean. But this upgrade of unsupported is annoying.

Actual behavior

The un-supported version "1.12.10983.0" displayed when running "winget upgrade" in Win10 terminal.

Environment

Windows Terminal version
1.12.10982.0

Windows build number
10.0.19044.0

Winget version
v1.3.431-preview

[ali50m]

microsoft/terminal#13008

[denelon]

This looks like we need to add more metadata so we can check the Minimum OS Version in addition to the other installer metadata when we run the upgrade command.

---

Edit:

This is due to the installer requiring Windows 11 as the minimum OS version.

Current workaround:

winget show Microsoft.WindowsTerminal --versions

Install the previous version listed as it supports Windows 10 as the minimum OS version.

winget install Microsoft.WindowsTerminal --version 1.12.10982.0

[robinmalik]

I suppose what I'm seeing is related to this. On W10 and seeing this in the upgrade available:

Windows Terminal Microsoft.WindowsTerminal 1.12.10982.0 1.12.10983.0 winget

When trying to upgrade:

No applicable update found.

Even trying winget install Microsoft.WindowsTerminal gives:

No applicable installer found; see logs for more details.

[dpprdan]

winget install Microsoft.WindowsTerminal fails as well, see microsoft/winget-pkgs#59427 (comment)

[OfficialEsco]

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

[Trenly]

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

[Banner-Keith]

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

[denelon]

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

[Trenly]

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

[JohnMcPMS]

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

That won't resolve this particular issue, as I would expect that to be "if ALL versions of a package have a min OS higher than the current one, don't consider it as existing". However, if at least one version is applicable, we would consider it, and the user would want us to. 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.

There is the consideration of filtering individual versions at the search layer to make some things a cleaner user experience, which could be a way to fix this issue. But it is by far more expensive than the simple fallback (which will work for ALL cases of inapplicability now and in the future).

Edit: I only read the latest comments and thought this was about install. For upgrade yes, we would need to filter each version by applicability factors. OS version is only one of those.

[dpprdan]

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

[Trenly]

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.

[JohnMcPMS]

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

[Trenly]

(and even then, should winget show foo --versions list inapplicable version with an *?)

I would say Yes

We could output N/A or similar as the version to indicate in search "we have this thing, but not for you".

I think this is a great approach

I wouldn't want to do this for just the OS version; it would be for all applicability concerns.

Agreed - Reparse points, virtualization, unsupported OS Architectures, unsupported OS Versions, all if it is good

---

@jedieaston @OfficialEsco - Would it make any difference if we were to split the packages like Microsoft.WindowsTerminal.Win10 and Microsoft.WindowsTerminal.Win11 ? Or would that still cause issues because of #1951 ? Is there any way we can use ARP data to disambiguate if we split the packages?

[denelon]

@JohnMcPMS does that include the changes for the publishing pipelines? How many bugs here at GitHub would that resolve?

Applicable Installer Dimensions:

• Minimum OS Version
• Locale
• Architecture
• Scope
• Platform
• Installer Type

What did I miss?

[denelon]

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

[Trenly]

@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

[dpprdan]

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

[OfficialEsco]

Splitting Windows Terminal is a terrible idea since the ARP data is the same, the only difference is the DisplayVersion and ProductCode, it will be worse than VC++ because it does not contain any real indicators (or well the current regex is currently making VC++ only match by ProductCode).

In theory its easier to maintain VC++ because the versions are more mainstream, however someone could have disabled Microsoft Store updates so their Windows Terminal is super outdated.

[Trenly]

the only difference is the DisplayVersion and ProductCode

Yeah, I was thinking that we could possibly just do product code, but you're right, it would be the same issue we have with VC++

[onebitbrain]

This issue is getting worse. I now have 3 packages that appear in winget upgrade but won't upgrade when running winget upgrade --all. One of the dotnet sdks will download repeatedly every time an upgrade --all is run. The common denominator seems to be these are all Microsoft pkgs.

[dpprdan]

@onebitbrain FWIW I see MinimumOSVersion: 6.1.7601 (i.e. Windows 7, Service Pack 1 or Windows Server 2008 R2, Service Pack 1) in the dotnet 6.3.22.22103 manifest, so this seems to be a different problem.

[OfficialEsco]

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.

• Upgrading Microsoft.dotnet fails, multiple versions installed #1142
• Upgrading Microsoft.dotnet fails when multiple major versions are installed side-by-side #2011
• Incorrect PackageName for Microsoft.dotnetRuntime winget-pkgs#17985
• [Bug]: Winget is reporting a .NET 6.0 SDK package as an update for a .NET 5.0 SDK installation. winget-pkgs#38045

[denelon]

The .Net team will be managing all their manifests directly. They made an announcement about the upcoming breaking changes.

We still have the versioning change feature to begin switching to the displayVersion rather than packageVersion for upgrade comparison to address the majority of the remaining issues.

[marcinsmialek]

This affects more apps, like PowerShell installer.
I've tried App Installer from store, and manually updated to 1.3 available here, as Store updater couldn't find the latest version. Clicking from Explorer failed with uninformative error "This app package is not supported for installation by App Installer because it uses certain restricted capabilities". Installing via Add-AppxPackage worked and updated winget.
The effect from 1.2 and 1.3 upgrade attempts was the same.
I'm on Windows 11 22H2 (OS Build 22622.575)

winget --info
Windows Package Manager v1.2.11601
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22622.575
Package: Microsoft.DesktopAppInstaller v1.17.11601.0

winget --info
Windows Package Manager v1.3.2091
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22622.575
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.18.2091.0

winget upgrade
Name                                    Id                                      Version          Available       Source
-----------------------------------------------------------------------------------------------------------------------
...
PowerShell 7.2.5.0-x64                  Microsoft.PowerShell                    7.2.5.0          7.2.6.0         winget
...

winget upgrade PowerShell
No installed package found matching input criteria.

This is the only package with "PowerShell" in name. These give the same error:

winget upgrade --id "Microsoft.PowerShell" --include-unknown
winget upgrade --id Microsoft.PowerShell --include-unknown
winget upgrade --id "Microsoft.PowerShell" --version 7.2.6.0 --include-unknown

These commands show the current lates version 7.2.6:

winget show Microsoft.PowerShell
winget show Microsoft.PowerShell --versions

[denelon]

If you winget install Microsoft.PowerShell do you get an error or do you end up with multiple entries?

[denelon]

Work in progress:

• [Package Request]: Microsoft.UI.Xaml winget-pkgs#111840
• Proposal: Automate publishing to WinGet Community repository microsoft-ui-xaml#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.

[denelon]

This was happening in this case because two versions of Terminal needing to be released to target separate versions of Windows had separate version numbers. WinGet didn't handle this situation correctly.

WinGet now fully supports dependencies for package manifests, so the other thing that was happening is packages were in some cases getting their dependencies satisfied by virtue of WinGet being installed. When drift for versions happened, some of the earlier versions of packages would fail.

I'm going to go ahead and close this bug related to Terminal since it's well beyond resolved. I believe there is already an issue to handle the different OS requirements based on different package versions.