Introduce additional versioning information for casks

[razvanazamfirei]

Verification

• This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature

Precise naming of the DSL aside, I'm opening this to discuss introducing additional versioning information for casks.

We would introduce an additional DSL/modify existing DSLs to record the canonical cask version (CFBundleShortVersionString). In situations where we need additional information to resolve the download URL, they should be recorded separately. This could look like this:

version "0.69.2"
download_string "f2822fbb-5d33-41be-90eb-be140fe649b0,0252"
url "https://example.com/#{download_string.csv.first}/#{download_string.csv.second}/cask#{version}.dmg"

or, assuming CFBundleShortVersionString is 3.0.5, but the url link uses a build number 1321321

version "3.0.5"
download_string "1321321"
url "https://example.com/cask#{download_string}.dmg"

However, all casks would be stored under their canonical version.

What is the motivation for the feature?

Currently, we structure our cask versions to include all the strings that change between and are necessary to build a download URL. This sometimes leads to nonsensical versions (e.g., version "0.69.2,f2822fbb-5d33-41be-90eb-be140fe649b0,0252") or versions that are unrelated to the canonical software version.

This makes it difficult to deal with issues like #17051 and prevents us from implementing audits that check the cask version agains the distributed version.

How will the feature be relevant to at least 90% of Homebrew users?

Opens door to potential workflow and security improvements for casks

What alternatives to the feature have been considered?

Not implementing the feature, which is also reasonable.

[razvanazamfirei]

Tagging @Homebrew/cask.

[SMillerDev]

What would be the benefit for Homebrew to do this? I see "This makes it difficult to deal with issues like #17051 and prevents us from implementing audits that check the cask version agains the distributed version.", but it is unclear to me why we would want to compare those versions.

It is my understanding that this only works for app type installs, and that there is no real check for developers that these versions need to make sense. AFAIK I can make an app with CFBundleShortVersionString of 1.5.1 and put it online as version 5.0. I don't see what the benefit for maintainers or users would be to keep track of such an implementation detail.

[MikeMcQuaid]

but it is unclear to me why we would want to compare those versions.

The main case that's somewhat obvious to me: have brew outdated and brew upgrade actually be accurate for Casks that auto-update.

All the --greedy handling is pretty wasteful really; Homebrew doesn't really differentiate between "upgrading from v1 to v2" and "upgrading from v1 which already auto-updated to v2 to v2 essentially changing nothing in the application but changing the name of the Caskroom".

[SMillerDev]

The main case that's somewhat obvious to me: have brew outdated and brew upgrade actually be accurate for Casks that auto-update.

Yeah, that one makes sense to me, although that wouldn't really need DSL changes right? We could just enforce that the first part of the version should always be the "real version"

[bevanjkay]

I can't confidently speak to the quantity, but some applications maintain the same "version", but will increase build number, or another iteration, where comparing the info.plist may not be accurate. I think we would find some inconsistencies there because it's not an "enforced" standard, so vendors handle it differently.

[MikeMcQuaid]

Yeah, that one makes sense to me, although that wouldn't really need DSL changes right?

Wouldn't need DSL changes but might want a new DSL to adjust behaviour here rather than assuming all casks are consistent.

I can't confidently speak to the quantity, but some applications maintain the same "version", but will increase build number, or another iteration, where comparing the info.plist may not be accurate. I think we would find some inconsistencies there because it's not an "enforced" standard, so vendors handle it differently.

@bevanjkay That's fine unless you think the vast majority of casks do this (which I don't think they do). There will always be exceptions and making things better for some casks but not all is worth it IMO.

This does again point to perhaps a need for a DSL to handle this inconsistency, though.