App versions with a different version text locally & in Mac App Store cause problems for update & outdated

[Accademia]

mas version

v1.8.8-beta.13

macOS version

15.1.1

macOS build version

24B91

Processor

Apple M3 Max

mas installation method

Homebrew core (brew install mas)

mas installation details

Expected behavior

The latest version of MAS may cause an update error with ASUS Device Discovery., details are as follows:

―― macOS App Store ――
Upgrading 1 outdated application:
ASUS Device Discovery (1.1.18) -> (1.0.0.1.18)
==> Downloaded ASUS Device Discovery (1.1.18)
==> Installing ASUS Device Discovery (1.1.18)
==> Installed ASUS Device Discovery (1.1.18)
―― macOS system update ――
No updates are available.
Software Update Tool

Actual behavior

Steps to reproduce

topgrade

Additional context

No response

[rgoldberg]

@Accademia mas compares the version from the app itself against the version for the app from the Mac App Store.

ASUS used 1.1.18 as the version in the app itself, while they used 1.0.0.1.18 as the version in the Mac App Store.

The ways around this would be to:

• somehow find the equivalent of the local app version in Mac App Store data, or the Mac App Store version in the local data (I haven't found either after a quick investigation)
• compare some other version identifier between the local app info & the Mac App Store info (like the kMDItemAppStoreInstallerVersionID property from Spotlight, which doesn't seem to be available from the Mac App Store endpoint that we use)
• somehow ask if there are updates for any of the installed apps, rather than mas itself comparing the local app version with the Mac App Store app version
• always ask for an update for each relevant app, but ensure that no updates are unnecessarily downloaded or are installed

[Accademia]

@Accademia mas compares the version from the app itself against the version for the app from the Mac App Store.

ASUS used 1.1.18 as the version in the app itself, while they used 1.0.0.1.18 as the version in the Mac App Store.

The ways around this would be to:

• somehow find the equivalent of the local app version in Mac App Store data, or the Mac App Store version in the local data (I haven't found either after a quick investigation)
• compare some other version identifier between the local app info & the Mac App Store info (like the kMDItemAppStoreInstallerVersionID property from Spotlight, which doesn't seem to be available from the Mac App Store endpoint that we use)
• somehow ask if there are updates for any of the installed apps, rather than mas itself comparing the local app version with the Mac App Store app version
• always ask for an update for each relevant app, but ensure that no updates are unnecessarily downloaded or are installed

Thank you very much for your response! Thank you for resolving my confusion.

[rgoldberg]

@Accademia Thanks for the issue report.

It will probably take some time to get to this, as there are other pressing issues in the task queue, and because solving this will probably require extracting headers for private frameworks from the DSC for multiple macOS versions, which will take time to get working (it's a long story).

[rgoldberg]

@Accademia See note at the beginning of #386 to see how version ignoring might mitigate this issue.

mas upgrade could check each "upgraded" app after the "upgrade" finished; if the same version to which the app was "upgraded" is still offered as an upgrade, then it could output a suggestion to the user to use a command-line like the following to ignore the seemingly spurious update in the future. e.g., for your app:

mas pin --exclude '1\.0\.0\.1\.18' 995124504

Unfortunately, the pin would need be changed after real every upgrade to a new version if they continually insert .0.0 in their Mac App Store versions. We could try to allow a syntax where the exclusion could generically reference the current version, i.e. it would ignore anything matching <current-major-version>\.0\.0<current-version-after-major>, so the pin wouldn't need to be updated after every real upgrade, but that will probably be way too much work for way too little gain.