`cask upgrade` will be downloaded and installed repeatedly about brew

[bevanjkay]

Suggest modifying brew upgrade --cask to judge the current installed version number. For example, by using defaults read /Applications/Google\ Chrome.app/Contents/Info.plist CFBundleShortVersionString to determine if the installed version

This sounds like a decent solution.

Regarding the general behaviour of brew upgrade.
I would note that calling brew upgrade without explicitly referencing google-chrome, will not upgrade casks that have the auto_updates true flag set. Calling brew upgrade google-chrome directly implies that you would like to upgrade Google Chrome regardless of whether it has an auto-update mechanism.

[missuo]

Suggest modifying brew upgrade --cask to judge the current installed version number. For example, by using defaults read /Applications/Google\ Chrome.app/Contents/Info.plist CFBundleShortVersionString to determine if the installed version

This sounds like a decent solution.

Regarding the general behaviour of brew upgrade. I would note that calling brew upgrade without explicitly referencing google-chrome, will not upgrade casks that have the auto_updates true flag set. Calling brew upgrade google-chrome directly implies that you would like to upgrade Google Chrome regardless of whether it has an auto-update mechanism.

I think we should check for the existence of automatic update mechanism before performing the update operation.

For example, when executing brew upgrade google-chrome --cask, if the automatic update mechanism has already updated Chrome to the latest version, there is no need for Homebrew to redownload and reinstall it. Only updating the version number in the brew database is sufficient.

[bevanjkay]

Only updating the version number in the brew database is sufficient.

The only challenge with a cask such as google-chrome is that the download is actually unversioned, so although the cask has been updated to a newer version, the version that is downloaded may be different. So a true comparison cannot be completed without downloading the files.

[missuo]

~ defaults read /Applications/Google\ Chrome.app/Contents/Info.plist CFBundleShortVersionString
123.0.6312.107

It seems that I can accurately get the version number of Chrome, and of course, the situation you mentioned may indeed occur.

[MikeMcQuaid]

Calling brew upgrade google-chrome directly implies that you would like to upgrade Google Chrome regardless of whether it has an auto-update mechanism.

Agreed, and this makes sense to me.

Only updating the version number in the brew database is sufficient.

There is no database here. The version is stored in a folder name on disk e.g. /opt/homebrew/Caskroom/google-chrome/123.0.6312.107/. Updating the contents of this folder will require pretty much the same time as all but downloading the existing change.

I'm also not necessarily convinced that the version in the plist should mean that an upgrade should not happen. This would not upgrade based on e.g. actual changes to the Cask file contents, potentially ever.

brew info --json=v2 google-chrome | jq '.casks[0]'.bundle_short_version will output this short version and we are able to query it with Cask internals, I'm just not sure it should be tied to the brew upgrade case specifically.

---

Leaving this open for other Cask folks to chip in but, personally, I'm 👎🏻 on the changes described here.

[razvanazamfirei]

I would note that calling brew upgrade without explicitly referencing google-chrome, will not upgrade casks that have the auto_updates true flag set. Calling brew upgrade google-chrome directly implies that you would like to upgrade Google Chrome regardless of whether it has an auto-update mechanism.

I think our current approach here is reasonable and not sure if adding an additional layer of complexity here makes sense. Casks do not have consistent versioning schemes and occasionally, the scheme will be completely unrelated to CFBundleShortVersionString. This is a great idea in theory, but not super feasible IMO. Personally, I would pass on this. Sorry!

[missuo]

Thank you for considering this idea. Thank you for your contributions.

[MikeMcQuaid]

Thanks for your understanding @missuo!

[MikeMcQuaid]

Casks do not have consistent versioning schemes and occasionally, the scheme will be completely unrelated to CFBundleShortVersionString.

@razvanazamfirei @Homebrew/cask Relatedly: I do think making versions either the short version string or version string where possible (and a DSL to indicate which one is used) would make life much better around these sort of issues in future.

[bevanjkay]

It's always the goal, but we basically need to collect whatever is required to assemble the url dynamically as the "version". Alternative would be to split the version dsl, to have the actual version, and then any additional dynamic url parts.