Cask wordpresscom: fix livecheck and add arm64

[toobuntu]

Output of brew config

HOMEBREW_VERSION: 4.1.25-69-ga60c58c
ORIGIN: https://github.com/Homebrew/brew
HEAD: a60c58c798c4e0e2bdc6b8cbdbddc87302a30d2a
Last commit: 14 hours ago
Core tap origin: https://github.com/Homebrew/homebrew-core
Core tap HEAD: ea9fd27f84a5e6af98ab0665628109f55ae5b5a2
Core tap last commit: 9 hours ago
Core tap branch: master
Core tap JSON: 16 Dec 19:46 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_AUTOREMOVE: set
HOMEBREW_BAT: set
HOMEBREW_BAT_THEME: ansi
HOMEBREW_BOOTSNAP: set
HOMEBREW_CASK_OPTS: []
HOMEBREW_CLEANUP_MAX_AGE_DAYS: 30
HOMEBREW_CLEANUP_PERIODIC_FULL_DAYS: 1
HOMEBREW_DEVELOPER: set
HOMEBREW_EDITOR: vim
HOMEBREW_GITHUB_API_TOKEN: set
HOMEBREW_MAKE_JOBS: 8
HOMEBREW_NO_ENV_HINTS: set
HOMEBREW_SORBET_RUNTIME: set
Homebrew Ruby: 3.1.4 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/bin/ruby
CPU: octa-core 64-bit arm_blizzard_avalanche
Clang: 15.0.0 build 1500
Git: 2.43.0 => /opt/homebrew/bin/git
Curl: 8.4.0 => /usr/bin/curl
macOS: 14.2-arm64
CLT: 15.1.0.0.1.1700200546
Xcode: 15.1
Rosetta 2: false

Output of brew doctor

Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: Some installed formulae are deprecated or disabled.
You should find replacements for the following formulae:
  youtube-dl

Description of issue

Cask wordpresscom has the following out-of-date:

• The livecheck seems to not work correctly.
• It lacks support for Apple Silicon, although there is a download for it from wordpress.com.

And the following point to consider for any updates to the cask:

• There is a deployment repository on GitHub.

Issues/Questions

1. Livecheck: Keep the url at wordpress.com. But it seems strategy :extract_plist ... .short_version will be required for it to work.

2. Livecheck: Alternatively, the livecheck can point to the deployment repository and use strategy :github_releases with json parsing to skip the betas.

3. Url: Additionally, the download url itself could point to the deployment repo.

4. Url: The download can be either zip or dmg.

What would be the preferred way of going forward with this?

[SMillerDev]

https://docs.brew.sh/Updating-Software-in-Homebrew

[toobuntu]

Thank you!

That is exactly what I would like to do: submit a PR.

I hope to receive policy guidance so the PR is more likely to be accepted.

• Is there a preference for zip over dmg?
• Is there a preference for an “official” download site over a GitHub deployment repo (which is also maintained by upstream)?
• Is github_releases preferred over extract_plist? It seems from the docs that neither is liked very much.

The PR would look quite different depending on the answers.

Thank you for such a great project, and for taking the time to engage in this discussion.

[SMillerDev]

Is there a preference for zip over dmg?

Whatever upstream suggests

Is there a preference for an “official” download site over a GitHub deployment repo (which is also maintained by upstream)?

Whatever upstream refers to as the place to download things

Is github_releases preferred over extract_plist? It seems from the docs that neither is liked very much.

Depends on what the options are, :extract_plist requires a full binary download so it is the slowest option, but sometimes it's also the most accurate.

[toobuntu]

Thank you again for sharing your expertise. I'll jot down my research and thoughts here.

Is there a preference for zip over dmg?

Whatever upstream suggests

So they don't really "suggest" one or the other that I can see. They provide both. The website had me downloading a dmg, so maybe that means something. Or not.

Is there a preference for an “official” download site over a GitHub deployment repo (which is also maintained by upstream)?

Whatever upstream refers to as the place to download things

This one is interesting.

• desktop/app/config.json defines for "build": "release":

	"updater": {
		"downloadUrl": "https://apps.wordpress.com/desktop/",
		"apiUrl": "https://api.github.com/repos/Automattic/wp-calypso/releases",

• desktop/desktop-config/config-release.json defines for "build": "release":

	"updater": {
		"downloadUrl": "https://apps.wordpress.com/desktop/",
		"apiUrl": "https://api.github.com/repos/Automattic/wp-desktop/releases",

• desktop/desktop-config/config-updater.json defines for "build": "updater":

	"updater": {
		"downloadUrl": "https://github.com/Automattic/wp-desktop/releases",
		"apiUrl": "https://api.github.com/repos/Automattic/wp-desktop/releases",

• desktop/desktop-config/config-development.json defines for "build": "development":

	"updater": {
		"downloadUrl": "https://apps.wordpress.com/desktop/",
		"apiUrl": "https://api.github.com/repos/Automattic/wp-desktop/releases",

So all use the GitHub API. Which means to me that it is fair to use GitHub for the livecheck stanza to avoid using :extract_plist there.

The choice of download url seems not to matter to upstream, as they use both. It looks like the in-app updater exclusively uses GitHub internally. So it again seems fair game to use GitHub, which is so common elsewhere within the Homebrew ecosystem and might make it easier to support both intel and arm in the cask. But I totally get it if maintainers want to continue to use the upstream website for that.

Is github_releases preferred over extract_plist? It seems from the docs that neither is liked very much.

Depends on what the options are, :extract_plist requires a full binary download so it is the slowest option, but sometimes it's also the most accurate.

See the previous response.