Improve app version comparison

[eatstorming]

I just started using MAS yesterday and I ran into a weird issue. One of the apps I use (Spark Mail) recently had an update where the version number has a space, seemingly by mistake: 2. 11.9

This seems to throw off MAS every time I run mas upgrade:

   ~  mas outdated
1176895641 Spark (2.11.9 -> 2. 11.9)
   ~  mas upgrade
Upgrading 1 outdated application:
Spark (2.11.9)
==> Downloading Spark – Email App by Readdle
==> Installed Spark – Email App by Readdle 
   ~  mas upgrade
Upgrading 1 outdated application:
Spark (2.11.9)
==> Downloading Spark – Email App by Readdle
==> Installed Spark – Email App by Readdle
   ~  mas outdated
1176895641 Spark (2.11.9 -> 2. 11.9)
   ~ 

So my guess is that the space in the version is throwing the check off.

I tried to check the code, and got as far as seeing that isOutdatedWhenComparedTo uses Version to compare store version to the installed version, but after that I was unable to check if Version has any parameters that allow it to strip off spaces from the string being passed to it. I'm also not sure if deliberately changing bundleVersion to do this could have unexpected issues down the line.

Lastly, I'm also aware that in this case it's likely that the issue will fix itself once a new update to the app comes out, hopefully without the "typo" in the version number, but I'm wondering if this is something MAS should handle better. The App Store GUI does not have the same issue, as checking for updates does not find anything new for Spark (and I've had a few other apps updated since the latest Spark one).

[chris-araman]

Unfortunately, App Store versions are not as well-defined as Semantic Versions. They're just strings.

mas does the best it can given the information exposed by CommerceKit and StoreFoundation. I agree that the space is likely causing mas some trouble.

Do you have a specific improvement to suggest? Pull requests are welcome! In general, though, finding ways to handle one-off cases like this in a general way that does not introduce unexpected behavior for other cases is problematic at best.

Would further clarification in Known Issues be helpful?

[eatstorming]

Unfortunately, App Store versions are not as well-defined as Semantic Versions. They're just strings.

mas does the best it can given the information exposed by CommerceKit and StoreFoundation. I agree that the space is likely causing mas some trouble.

Do you have a specific improvement to suggest? Pull requests are welcome! In general, though, finding ways to handle one-off cases like this in a general way that does not introduce unexpected behavior for other cases is problematic at best.

Cool. I'll play with it once I got some time and see if I can fix it, then push a PR if I can do it.

Would further clarification in Known Issues be helpful?

Maybe, but I like how the Known Issues are now: it covers a more common list of cases in my opinion. This one is a one-off but maybe similar cases will happen from time to time, so I guess up to you.

[rgoldberg]

@phatblat We will probably need to either semantically compare versions or compare version release dates because the App Store seems to work on eventual consistency. If an app is upgraded to a new version, we might get outdated version info from the store the next time we use the iTunes Search API, so trying to upgrade on any different version could cause unnecessary upgrade attempts.

The iTunes Search API results include the current version release date, so, if we can find the release date of the version installed on the user's computer, we could compare those, and not have to worry about poorly formatted version strings, but I haven't found that date yet for installed versions of apps.

We also need to investigate getting the latest version of an app that will run on the user's current macOS version, which might be a different app version than the latest. That might affect this issue, too, but hopefully wouldn't.