Inconsistent version display causes winget to detect updates

[lvzhenbo]

Description

I updated the software by downloading the package, but when I use winget to detect the software update, I found that there is an update, and then the local display version number is 10.4.0.0, while the remote version number is 10.4.0.35, the local display version is not the same as the version of the software

Expected Behavior

winget should not be able to detect the update, the version number should be the version number of the software itself

Log Data

unnecessary

Commit Hash, Version and Windows Build

• Commit: 57ef363
• Service/App: 10.4.0.35
• Updater: 3.1.4
• Shell: 1.3.3.0
• .Net: 7.0.5
• Windows: 22621.2283

Screenshots / Videos

No response

[Spiritreader]

Innosetup does not support build numbers, hence the installer will report 10.4.0.0.

Could you explain what exactly is happening?
If our windows store version is 10.4.0.0, and you have used our updater to update to 10.4.0.35, how is winget telling you to update, if your local version is newer than upstream?

Or am I misunderstanding anything here?

[lvzhenbo]

It is like this, winget detects the software according to the version number registered in windows, the registered version number is 10.4.0.0, but the software repository maintainer of winget writes according to the real version number, which is 10.4.0.35, according to the algorithm of winget, it is bigger than the registered version number, which leads to the software itself is the same version, but winget can detect the version update, that is, no matter how many times the update is installed through winget, it will always be detected. However, winget is able to detect the version update, that is, no matter how many times the update is installed through winget, the update will be detected all the time.

[lvzhenbo]

10.4.0.35 > 10.4.0.0 update

[Armin2208]

Yes, the Auto Dark Mode Setup doesn't set the build number on the version number for the app list. This is why Winget thinks an update for Auto Dark Mode is available, although it isn't.

The integrated Updater of Auto Dark Mode sets the build number for the app list. So after updating via Auto Dark Mode itself, Winget shouldn't detect any updates. And yes, the upgrade from 10.3 to 10.4 required a setup installation. But only once, in the future the Auto Dark Mode Updater will done the job and will not confuse Winget.

What can you do?
You can pin Auto Dark Mode on Winget. The pin feature of Winget skips updates for pinned package.
Try using: winget pin add "Auto Dark Mode".
After pinning Auto Dark Mode, it should be on the list winget pin list.
You can now safely use winget upgrade without updating Auto Dark Mode.

What can we do?
@Spiritreader it seems like InnoSetup has the support for build numbers, at least in the config file.
See the InnoSetup documentation, it allows putting four numbers into VersionInfoVersion.
But it's hard to automate, because it would need a constant change of the version number in the InnoSetup config file? Maybe there are some easier ways of automatization?

[Spiritreader]

Yes, the Auto Dark Mode Setup doesn't set the build number on the version number for the app list. This is why Winget thinks an update for Auto Dark Mode is available, although it isn't.

The integrated Updater of Auto Dark Mode sets the build number for the app list. So after updating via Auto Dark Mode itself, Winget shouldn't detect any updates. And yes, the upgrade from 10.3 to 10.4 required a setup installation. But only once, in the future the Auto Dark Mode Updater will done the job and will not confuse Winget.

What can you do? You can pin Auto Dark Mode on Winget. The pin feature of Winget skips updates for pinned package. Try using: winget pin add "Auto Dark Mode". After pinning Auto Dark Mode, it should be on the list winget pin list. You can now safely use winget upgrade without updating Auto Dark Mode.

What can we do? @Spiritreader it seems like InnoSetup has the support for build numbers, at least in the config file. See the InnoSetup documentation, it allows putting four numbers into VersionInfoVersion. But it's hard to automate, because it would need a constant change of the version number in the InnoSetup config file? Maybe there are some easier ways of automatization?

Hm aight. Last time I tried it it didn't work, and it just ignored that value, but I can check and try again.

[aaronliu0130]

@lvzhenbo the winget thing would be fixed by microsoft/winget-pkgs#120000 .

[aaronliu0130]

I don’t think this should be closed, not displaying the build number is still a problem.

[Spiritreader]

I don’t think this should be closed, not displaying the build number is still a problem.

This issue is about winget though.
New stable releases will always have at least their minor version changed, and on the next release the installer will include the version number again (assuming this works now with inno setup)

[aaronliu0130]

It’s a two parter, the WinGet was just a consequence of the version display. If the next release still don’t give the right version number then this should be reopened.