Add Safari Technology Preview latest

[zmwangx]

https://developer.apple.com/safari/technology-preview/
https://webkit.org/blog/6017/introducing-safari-technology-preview/

[lukeadams]

Shouldn't there be an SHA? The download link is over HTTP, and the binary isn't a rolling release (as seen in the changelog).
I got SHA256:ec41f9ae51524ac0fa97cde0a3b55e52657f4998ce5e439ab9ba3af3d6e32c1a for Release 1.

Here's an encrypted URL: https://secure-appldnld.apple.com/STP/SafariTechnologyPreview.dmg

[zmwangx]

the binary isn't a rolling release

It should be a rolling release, but updates beyond initial installation will be distributed through MAS (every two weeks). Presumably the download URL should point to the latest binary (there's no reason to believe otherwise).

Here's an encrypted URL

Updated, thanks.

[lukeadams]

updates beyond initial installation will be distributed through MAS

Sweet!

Presumably the download URL should point to the latest binary (there's no reason to believe otherwise).

I thought I had found a direct link to the specific release, but that was not the case (which is why I claimed that it wasn't). My bad.

[vitorgalvao]

Remove comment.

[zmwangx]

Will do.

[zmwangx]

Fixed.

[vitorgalvao]

@caskroom/maintainers What do you think? Should this be here or in caskroom/versions?

[adidalal]

Seems like versions would be better (the other firefox versions are there, I think)

[zmwangx]

Adding a cask says

When an App’s principal stable version already exists in the main repo, alternative versions should be submitted to caskroom/homebrew-versions.

That's why I submitted here — there's no way Safari will ever be vendored by HBC.

[adidalal]

That's true - though will this link consistently work/be updated? I thought it was updated only via MAS

[zmwangx]

The blog post didn't say whether this link will always point to the latest binary, but IMO there's no reason they would ask you to download an outdated version, then wait for MAS to check for an update.

[timsutton]

My guess is that Apple will update the web download versions (eventually) and they will offer updates to the Safari TP via their software update servers, checking for bundle versions of com.apple.SafariTechnologyPreview (and/or package receipts for its installer package). If they do it via the MAS engine they would need to first have users "adopt" the app as a purchase that's tied to an ID.

But either way users will see the updates in the MAS and not need to care which backend is actually doing the check and update installation.

[vitorgalvao]

That's why I submitted here — there's no way Safari will ever be vendored by HBC.

That’s what gives me pause as well. Not sure yet what the best repo for this might be.

[zmwangx]

Just added a zap stanza. There's one plist in ~/Library/Preferences/ByHost/ that contains a UUID, so that one can't be removed until globbing support comes to delete:.

[timsutton]

This probably goes for a bunch of different casks and is probably worth an issue of its own, but since OS X added a preferences caching daemon in 10.8 it's not really best practice to interact with preferences by modifying plists directly. cfprefsd marshals any prefs API calls to and from plist files on disk, but the storage is a private detail.

From Apple's 10.8 API notes on preferences:

"The on-disk property list files used by CFPreferences have always been a private implementation detail, but in previous releases, directly modifying them has mostly worked (though there are some potential data-loss issues for applications that do so, even on previous systems). In 10.8 and later, the CFPreferences agent process (cfprefsd) will cache information from these files and asynchronously write to them. This means that directly modifying plist files is unlikely to have the expected results (new settings will not necessarily be read, and may even be overwritten). You should use the NSUserDefaults or CFPreferences APIs, or the defaults(1) command, to interact with the preferences system."

So as suggested, you can instead issue a defaults command, i.e.

defaults delete com.apple.SafariTechnologyPreview

and for ByHost prefs:

defaults -currentHost delete com.apple.SafariTechnologyPreview

As long as these are always run in the context of the user whose preferences are being operated on.

Generally current-host prefs have device-specific info, and I'm not sure you'd necessarily want to clear what in this case is a key called SyncedTabsDeviceUUID, but I mainly just wanted to point out this distinction about how to best interact with preferences on OS X. It's a common misconception that prefs plist files can be safely manipulated directly on disk without having cached changes overwrite them.

[zmwangx]

It's a common misconception that prefs plist files can be safely manipulated directly on disk without having cached changes overwrite them.

I know (learned it the hard way a long time ago), but when you delete both the plist and the application that uses it, it doesn't really matter.

[Eitot]

For what it’s worth, webkit-nightly is also at caskroom/versions, despite not having a counterpart at caskroom/cask.

[vitorgalvao]

For what it’s worth, webkit-nightly is also at caskroom/versions, despite not having a counterpart at caskroom/cask.

That is actually an excellent point. I’m convinced. What about you, @adidalal?

[adidalal]

Sounds good - lets add it to /versions

[vitorgalvao]

Thank you for all your work on this, @zmwangx. The one in caskroom/versions is at issue #1865, in case you want to take a look.