Switch macOS update mechanism to static JSON mode

[t3chguy]

Notes: This allows the update server to be entirely static, such as a CDN or object store, as defined at https://github.com/Squirrel/Squirrel.Mac#update-file-json-format

This is a high risk change but has undergone manual testing. When we migrate packages.element.io over to R2 we won't be able to maintain the PHP script for Squirrel.Mac updating so have switched to its newer JSON mode. For backwards compatibility we will set up rewrites from https://packages.element.io/{desktop,nightly}/update/macos/ -> $/releases-legacy.json (file example) - this will instruct all clients still looking in the old path (outdated ones) to update to a modern build which looks at the new releases.json and handles update recognition itself.

---

Here's what your changelog entry will look like:

🚨 BREAKING CHANGES

• This allows the update server to be entirely static, such as a CDN or object store, as defined at https (#461).

[richvdh]

This allows the update server to be entirely static, such as a CDN or object store, as defined at https (#461).

This doesn't seem like a complete changelog entry.

[richvdh]

For reference, here is the proposal as I understand it.

The current update URL for macOS is something like https://packages.element.io/desktop/update/macos/?localVersion=1.11.10, and that returns a JSON response that looks like:

{ "url": "https://packages.element.io/desktop/update/macos/Element-1.11.15-universal-mac.zip" } 

(similarly for s/desktop/nightly/.)

However, importantly, if the version in the query string is up to date, it returns a 204 to indicate no update is necessary. This is problematic, because it is served by a PHP script.

The proposal is:

1. Set up a rewrite (? or a redirect?) from https://packages.element.io/nightly/update/macos/ to https://packages.element.io/nightly/update/macos/releases-legacy.json, which will return json of the same format:

   { "url": "https://packages.element.io/nightly/update/macos/Element%20Nightly-2022120101-universal-mac.zip" }

   (ditto for desktop). This need never return a 204, because any application hitting that URL must be out of date.

2. Tell the Squirrel updater to check https://packages.element.io/desktop/update/macos/releases.json instead, which will use an updated format.

[richvdh]

Seems plausible to me, though:

1. I wouldn't have minded a clearer walk-through of the current mechanism and why it won't work on R2, rather than having to figure it out myself.
2. The documentation at https://github.com/Squirrel/Squirrel.Mac#server-support makes it read like the 204 response is still a requirement. Are you sure it's not? (To be fair, it also says "you can store your update metadata on S3", so it's entirely believable that the docs are just wrong).
3. It would be nice if we could figure out a way to document that releases-legacy magic somehow so we remember what it's doing when we come back to it in a year's time
4. Currently these URLs are 404s. I take it that is not a problem?

[t3chguy]

You got it all bang on, apologies for not making it clearer straight off the bat.

Tell the Squirrel updater to check packages.element.io/desktop/update/macos/releases.json instead, which will use an updated format.

Yup, and instruct it to use that newer format, unfortunately it isn't smart enough to magically decide based on the response.

The documentation at Squirrel/Squirrel.Mac#server-support makes it read like the 204 response is still a requirement. Are you sure it's not? (To be fair, it also says "you can store your update metadata on S3", so it's entirely believable that the docs are just wrong).

All old clients will get a 200 OK (via transform [rewrite]) with the URL to update to a version which uses the new JSON mechanism, so will unconditionally tell them to update, then they'll never look at the file again. The docs are a little poor, but the last section is a complete alternative, having read the underlying Obj-C code and having performed tests, it works exactly as expected if you just read that last section on its own

It would be nice if we could figure out a way to document that releases-legacy magic somehow so we remember what it's doing when we come back to it in a year's time

It'll be implemented in terraform, we can make sure it is clear there

Currently these URLs are 404s. I take it that is not a problem?

They work fine for me, only thing lacking is the transforms
https://packages.element.io/nightly/update/macos/releases-legacy.json
https://packages.element.io/nightly/update/macos/releases.json
The /desktop/ ones not yet as there hasn't been a release since the element-builder changes landed, and don't need to be in place until the redirects are ready to enable.

[richvdh]

The docs are a little poor, but the last section is a complete alternative,

Ok, the docs really fail to make that clear, but thanks for double-checking!

The /desktop/ ones not yet

Right, it was the /desktop/ ones I was looking at. Fair enough, thanks.